Neat idea, but JS? Eww. Stab me in the eye, why don't you.

Vala – C#-ish syntax which compiles down to native code for the GTK+ widget set. (Article).

You lose the cross-platform-ness of .NET, but get the performance and
maturity of the GTK+ widget set.

It's kind of hawt.

Of course, if we can do this, why can't we write firmware in C# and
compile it down to raw C?

Oh, wait, we sortof can – look at D. I haven't poked it, but it looks to take a lot of the best bits of “modern” languages with the benefits of a traditionally compiled language.

Look at it like this – why are modern languages like C# and Java (and to a lesser extent, languages like PHP and Perl) good?
- Many libraries
- Modern OO features
- Write once, run anywhere*
- Automatic garbage collection (when it works)

And why are they bad?
- Slow
- Heavyweight

• = Theoretically, but not really. Think about it – without installing the Sun JRE, you basically can't run Java. Sure, there are other JREs, but I've found them all to often not work. Since Sun's JRE isn't included by default on Mac, most Linux, and Windows, it puts the onus on the user to install it.

Similarly, if you want to do C#, you have to install Mono (though maybe it comes with your distro) and unless the app has specifically been tested to work with it, it also likely won't work because it will throw an exception at some point.

This isn't to say that it's not gettingbetter, but we've been waiting for it to get good for years now.

Meanwhile, native-compiled code puts the onus on the developers to get it to build for all different platforms, and if you statically compile it, it will basically run forever, at least until the really basic system APIs change and it needs a recompile. Plus this is an issue has been solved – on most operating systems, you install (or it comes with) a repository and package management system and just yum, apt-get or fink install the natively compiled package which you want. (Windows folks are still stuck in the 1990's, and would have to manually download and install an app, but that works too).

Also, they generally have advantages of:
- speed
- flexibility
- the ability to talk to real hardware (which is still a problem with a lot of VM-based languages – you often end up having to include a library (written in C) in order to have something which can handle things like pointers so it can write data into registers).

So, yeah, I'll have to play with D… in theory, I might even be able to cross compile and write firmware in it.. Have I mentioned that Gumstix and Arduino are equally hawt.

(1) Keep youre[sic] code on the same level of indentation as much as possible.

Indenting is cheap, easy and helps you discern what code is in what blocks. Additionally, any decent modern editor will automatically indent for you, invalidating the crybaby point of it “required me to push the tab button four times”. Finally, the removal of bracing and multiple returns are the two big “thou shalt nots” of writing maintainable code. Why? Well, considering:

    if (foo)
        bar=3;

One then adds:

    if (foo)
        bar=3;
        baz=4;

And wonders why it doesn't run. The indenting is to the right level. But, crap, no braces. So:

When writing a conditional, always include the braces

Further, a variant on the second example:

    if(foo == bar)
    {
        return foo;
    }

    return quux;

Let's say you add a file close or db cleanup in there

    if(foo == bar)
    {
        close(file);
        return foo;
    }

    close(file);
    return quux;

And, then say, you add another thing:

    if(foo == bar)
    {
        close(file);
        return foo;
    }
    else
    {
        return baz;
    }

    close(file);
    return quux;

Congrats – you just left the file open.

So, another axiom:

There will be one and only one return statement.

Now, of course, the examples above are short – imagine if each of those conditionals was 80 lines long.

(2) Make sure that youre[sic] code describes itself.

Actually, I have very little problem with this, aside from the fact that the function may or may not be too specific, but is more likely just poorly named. Something like “AddYesterdaysTransactionsToList()” would likely be just as descriptive, but much shorter.

(3) Write good comments when necessary, but only then.

Actually, you want to write lots of comments, preferably in some variety of format which can be read by Doxygen, JavaDoc, nDoc, Sandcastle or similar. In this way, you have very nice documentation which you can use internally, and/or show to clients, auditors, etc. At a minimum, each function should have listed:

• What the function does.
• A list of arguments, including their type and how they are passed (by reference, pointers, in/out, etc… depends on the language)
• Function return values

In addition, aside from failing at code, they apparently fail at English (or, at least, choosing the proper version of “your”).
Edit: Apologies. He is not a native English speaker. Considering that, his English is quite good.

First, I'm a bit of a battery and flashlight whore, and I've ordered a lot from BatteryJunction, and not had a problem until recently – the AC adapter for my recently ordered Titanium 8 bay NiMH battery charger died after two days. I try the DC adapter in the car to make sure it isn't the unit, and it works just fine. So, it's the adapter. I send them an email asking them what I should do for warranty service and describing what I've done. Result? The next business day, I get an email that a warranty replacement pack has been shipped to me. No fuss, no muss, no hassle.

Second up is Indie Press Revolution. Now, none of these issues affected me personally, but they still sent out an email apologizing for the issues where they didn't get shipped some books in as timely a fashion as they were supposed to, and they were having problems with their SSL cert. They were straight up about it, and told folks what was going on.

Now, in the “good products” category:
- I recently picked up some skins from iStyles. Good selection, quality skins.

I do wish, however, that he had not fallen into the same traps as so many authors regarding such mundane things as computers and firearms – especially since Mr. DeSmedt's biography reveals him to have been a “computer programmer and system designer” at some point in his career.

Specifically:

• Firearms:
  1. Reference is made to “the smell of cordite”. Cordite is obsolete and is no longer used in modern ammunition.
  2. Glocks don't go click on an empty chamber. When empty, the slide will lock back. So, Marianna would know she was empty.
• Computers:
  1. The hacker Mycroft talks about how good his worm is in that it doesn't do naughty things like delete files and get itself noticed – it just phones home every 10 minutes seeing if it is needed. Guess what? That's supicious!. If you're a secret government agency, I'd hope that your border firewalls check outgoing connections and look for things like that.
  2. The worm also installs a telnet server, as evidenced by the target's desktop showing up on Mycroft's screen. Yeah, except telnet doesn't work that way, nor is it encrypted. SSH would have been a much better choice here.
  3. (This is probably a more general question about literature) Why do all of these reclusive hackers not have any guns? I mean, if I lived in the hills of North Carolina, one of my pasttimes would likely be shooting things. This is the same issue as when Bruce Willis and the Mac guy land on Kevin Smith's front yard in Die Hard 4 – dude has a generator and a ham radio, but no guns? WTF?

Those criticisms aside, as I said, I actually did like the book – enough so that I named my netbook Mycroft, following my tradition of naming computers after hackers in literature, as well as donating some money through podiobooks (I look at it as “I would have bought the book, and want to support the author, but don't feel the need to buy a book I've already listened to on the iPod”) and subscribed to Doctor Jack's Soapbox Seminars, a collection of physics related talks from the real life counterpart of the character in Mr. DeSmedt's book.

I also notice that Mr. DeSmedt lives in PA. If you happen to be a wargamer, and happen to be attending Cold Wars this year, and happen to read this blog entry, drop me an email (email address is in my user info) – I usually bring enough beer to share.