Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript follows the format established by Scott Meyers’s seminal Effective C++ but is arguably even more useful, thanks to the popularity of JavaScript and the many pitfalls and blind corners introduced by its syntactically forgiving, dynamically typed, shake-it-like-a-Polaroid-picture philosophy and coding style. Buy it, read it, forget it, read it again. This book is one for the desert island.

It’s probably fair to say that JavaScript has always had a bit of a problem with code quality. Derrick Pallas, writing for the Daily WTF, circa 2007, is representative of the frustration:

The advent of JavaScript has made it really easy to write web pages that interact with you. Really, it’s insanely easy. The barrier to entry: way too low. It’s not that all JavaScript is bad, just that most JavaScript is not written with simplicity, correctness, consistency, or completeness in mind.


Defensive Programming Example #1

The other day I stumbled across this bit of C# code, intended to randomly return one of four messages.

// Choose one of 4 messages to display randomly
string theMsg = "";
Random r = new Random();
    case 0: theMsg = "Hey!"; break;
    case 1: theMsg = "Whats up?"; break;
    case 2: theMsg = "Salutations."; break;
    case 3: theMsg = "Hail-"; break;
    default: throw new ArgumentException(); break;
return theMsg;

Few programmers would have trouble grokking what this code does. It’s intelligible and, in its current form, not too much of a maintenance headache. But defensive programming isn’t just about making your code intelligible; it’s about making your code tolerant to quick changes made under pressure, and incremental changes made over time, by people other than yourself, including the future version of yourself who no longer remembers the code.

In that light, this code has a lot of problems:


Of Gravatars and Robohashes

Webmasters who use Gravatar to decorate comments with custom avatar images will be familiar with the d parameter of the Gravatar image request.

<img src="http://www.gravatar.com/avatars/8ca7425c8a9da807b9bf6934f10d59fa.jpg?d=monsterid" alt="" />

You can specify values like monsterid, wavatar, identicon, or retro here and Gravatar will generate a unique avatar image corresponding to the MD5 hash of the user’s email address. You’ve seen these all around the web:

There are just a couple problems with these sets of generative graphics:


Coding the Tweet, Redux

A few months ago we built a simple Twitter desktop client with oAuth support using C# and .NET.

Since then, there have been some breaking changes in the Twitter oAuth implementation, including a new PIN-based authorization mechanism for desktop Twitter clients. If you’ve been getting 401 Unauthorized errors, this is probably why.


Coding the Tweet: Building a Custom Branded Twitter Application

UPDATE: The Coding the Tweet demo application and source code have been updated to support PIN-based authorization through oAuth.

With millions of users and an ecosystem saturated with over 700 custom applications, Twitter’s all the rage these days. Love it or hate it, Twitter has become a powerful medium for connecting with people and marketing your skills to a wider audience. As the saying goes:

Twitter marches on.


The Language Wars

Anybody who’s ever seen Full Metal Jacket will remember the U.S. Marine Corps Rifleman’s Creed:

This my rifle. There are many like it but this one is mine. It is my life. I must master it as I must master my life. Without me my rifle is useless. Without my rifle, I am useless. I must fire my rifle true. I must fire straighter than the enemy who is trying to kill me.

But what most people don’t know is that programmers live by a similar creed, albeit one that requires less courage:

This is my programming language. There are many like it, but this one is mine. It is my life. I must master it as I must master my life. Without me my language is useless. Without my language, I am useless. I must code my language true. I must code straighter than the enemy who is trying to take my job.

If you’re a programmer, you’re no stranger to the Language Wars.

  • C# vs. Java
  • C++ vs. C++/CLI
  • PHP vs. Ruby
  • VB.NET vs. C#

And if you’ve done any time “in country” then you know what there’s only one way to treat programmers of other languages: with poisonous rancor, sadistic undercutting, and general disdain.



Everybody knows that Visual Basic programmers are inferior, because Visual Basic for the longest time didn’t support object-oriented programming, or many of the abstractions that first-rate programmers require.


Everybody knows that C++ programmers are dinosaurs, clinging to an outmoded development paradigm, pointing out the useless performance of their language in an era when hardware has made most performance concerns moot.


And as for PHP programmers… don’t even get me started.

No matter who you are, or what language you program in: your stuff is better than the other guy’s stuff. At least, that’s the unspoken (or explicitly stated) assumption among many software developers, especially developers of the “guru” variety.

It’s also an assumption which is guaranteed to make you a poor programmer.

I’ve remarked before that technology is really just a way to help people instantiate ideas in a concrete form, through the process of what I like to call “reality engineering”. Every programming language ever invented is a means to that end, as is every screwdriver. So what do we achieve by religiously worshipping one particular programming language to the exclusion of all others?

We severely limit our options for the fluent and intuitive expression of our ideas.

In game terms, this would be like sitting down to a game of chess, across from a noted Grandmaster…

…and deciding, “Eh. I’m not going to use my Bishops. I don’t like Bishops, my organization doesn’t like Bishops, my fans don’t like Bishops. Rooks are much stronger.”

There are few technical decisions which are more important than the choice of language. It’s not enough to choose Language X because your organization is a political advocate for Language X. It’s not enough to choose Language X because that’s what the head architect wants to use. Choosing the right language is so helpful, and choosing the wrong language is so expensive, that the decision has to be made on the basis of its technical merits alone. What’s more: the choice of language has to be re-evaluated for every new project in your pipeline.

Otherwise you’re costing yourself and your organization time and money.

Choosing Between C++ and C#

During a recent Stackoverflow.com podcast, Jeff Atwood and Joel Spolsky discussed the question:

When is it correct to develop software (Windows software, in particular) in native C and/or C++?

Joel’s response was basically “almost never”. And while I wouldn’t state it quite that strongly, the point he was trying to make is that, for most applications, there exists some language X which is a better (meaning: more appropriate) choice then C++ and especially, C.

Without getting embroiled in language wars, I can agree with this statement. C# is cleaner and more intuitive than legacy C/C++. The overwhelming consensus among Microsoft developers is that C# is the more productive language. And for all but the most intensive of applications, developer productivity trumps all other considerations.

However, as a long-time C++ and C# programmer myself, I have to say that even though C++ is often the wrong choice, there are still many, many situations in which it’s the only choice:

  • Cutting-edge 3D games.
  • Graphical and audio workstation software.
  • Large-scale productivity applications like Adobe Photoshop.
  • Legacy codebases.
  • Real-time systems of all sizes and descriptions.
  • Anything involving extreme numerical computation.
  • Large-scale data storage and retrieval.
  • Device drivers.
  • And so forth.

No other language offers the performance characteristics of C++ together with support for such a rich set of abstractions. Managed programs can get very fast, thanks to JIT compilation’s ability to optimize for the native processor, but native C++ still outperforms managed C# across the board. And for any application where you need explicit control over large amounts of memory - for example, if you’re building an RDBMS - C#’s garbage-collected approach is a deal-breaker.

Of course, most developers aren’t sitting around coding 3D video games, or database engines. They’re creating enterprise software, probably web-based. Or they’re creating relatively lightweight desktop applications using WinForms. For these scenarios, C#, VB.NET, and or C++/CLI (also known as “managed C++”) are the choices that will give an organization the most bang for its buck, in the long run.

In the non-Microsoft world, the story’s a little different. If you want to program in C# for Linux, Unix, Solaris, et al., you’ll probably end up using Mono. And the thing about Mono is it’s open-source. Now, whatever your opinion on open-source development, one thing’s certain: the future of Mono on *nix platforms is more uncertain than the future of .NET on Windows platforms. Don’t get me wrong: Mono is supported by a thriving, vibrant developer community, and in all likelihood it’ll be around…oh…approximating on forever.

But it doesn’t have the weight of the Microsoft juggernaut behind it.

The thing about this particular question - I mean the question of C# vs. C++ - is that there just aren’t that many borderline cases. Usually, some characteristic of the project will jump out at you, and it’ll be obvious which language is appropriate. If you’re doing hardcore systems or application development, C++ is probably for you. For everything else, C# is probably way to go. And in practice you’ll find that it’s something like 80% C#, and 20% C++, give or take 10%.

Now, as hardware continues to improve, expect this percentage to change. If you don’t need the performance, there’s very little reason to use C++ these days at all. Managed C# applications running on today’s hardware are visibly faster than native C++ applications running on ten-year old hardware, and we can expect that trend to continue.

But as of right now: C++ is the only choice for hardcore application development. It’s just a question of deciding what hardcore really means, in the face of ever-more-powerful hardware.