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 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.

Stack Overflow Isn’t Always a Bad Thing

With summer just around the corner, Jeff Atwood and Joel Spolsky are up to no good, as usual.

The site is called, and if you haven’t heard about it, you soon will - if you’re a programmer, and if you don’t live under a rock.

It’s always dangerous to over-promote a thing before it actually exists, and is still very much a work in progress.

(By the way, I am not in any way affiliated or associated with, in case the above sentence made it seem like I am.)

I can’t think of two guys better suited to realize a project like this than Jeff and Joel.

But what is

In Jeff’s words:

Stackoverflow is sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit. It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

Have you ever searched for a choice tidbit of programming knowledge on Google, and stumbled across what looked like a picture-perfect result - exactly what you needed - only to find you were blocked from viewing the content by a site that required you to pay to view the answers?

I have, many times. I call it getting shafted by experts-exchange, and it’s bugged me for years.

It’s not that I’m against the experts-exchange “pay to get answers” approach. If that business model can be made to work, more power to you.

But the deliberate falsification of search engine results in order to encourage clicks, only to reward those clicks with a blatant “you must now pay us $X or we won’t show you the answer” is about as low as it gets.

My prediction (you heard it here first) is that within two years will be a household name - among programmers. Considering it doesn’t even have an official logo yet, I think that’s a fairly aggressive statement.

My other prediction: experts-exchange will go the way of the dodo bird if it doesn’t get its act together. You can’t charge for the same content the other guy is giving away for free, especially when the other guy’s content is better.

If you’re interested in learning more: check out the two podcasts currently available or stroll on over to

See you on the message boards-