Why You Should Learn C++

Not all software development projects can sustain a reasonable living. Anyone who has worked as a professional developer will take this truth as self-evident. It’s a sad occurance, but often developers for notionally worthy projects find themselves having to abandon their dreams and find gainful employment elsewhere. The failed startup and the abandoned open-source project are all-too-common manifestations of this.

I don’t have a solution for this problem, but I mention it in order to define a set P, which is the set of all software development projects that can sustain a reasonable living. Now let’s divide P into the subsets I and B.

The 010 Types Of Projects In The World

Let I be the subset of P that are Interesting projects. This is obviously a subjective criterion, but for the sake of argument I’m asking you to adopt my own definition. Interesting projects are characterised by being algorithmically complex, and performance sensitive. They possibly involve large amounts of data, or an intrinsically distributed problem domain, and almost always strongly linked to mathematics. In my time I have worked on some I-projects. Most recently: native-MPEG video splicing, network performance benchmarking, and real-time automated trading.

Let B be the complement of I. Again, I’ll ask you to adopt my subjective definition. Projects in the B set are typically data-centric, focusing on moving a bit of data from one place to another. There’s almost certainly a relational database in there somewhere. And probably a user interface with forms, into which mindless drones spend are to spend their days keying in meaningless data. It’s calledCRUD for a reason.

In order to make B-projects at all tolerable for the developers, they are typically sexed up with the use of inappropriate technology. Enterprisey solutions emerge, gratuitously over-engineered in the hope that developers won’t impale themselves on their own keyboards out of sheer boredom. It’s a sure sign that architectural astronautics has hit reality-escape velocity when terminology is co-opted from Interesting projects; so there is probably a web services “stack” and a message service “bus” in there somewhere. But to those who care to cast a critical eye, these projects are simply moving data from one place to another, with very little transformation or aggregation or any other algorithmically tricky task required along the way.

The Developer’s Dillema

So: you’re a developer. The most recent rent cheque has bounced and you’ve finally admitted to yourself that you need to shelve your world-changing open source project and go out and find a paying gig. Which type of project are you going to look for?

“Well, der,” you might think, having looked at the title of this article, “anything that doesn’t involve coding in C++! That language is acrock of shit!”

To which I say: not so fast there bub. I’m just going to put this out there; of the I-projects, that is projects that are interesting and pay the rent, a substantial proportion are written in C++. In other words, C++ is over-represented in the I-projects and under-represented in the B-projects.

All of my recent I-projects have been C++ projects. So, whatever you may think about the merits or otherwise of C++ as a language, it has great jobs. Hey, if nothing else, you’re not likely to have to deal with WS-*. This is a good thing.

This is a simplification: obviously the job involves more than just the project. You may have to deal with poor air conditioning, theVirtual Furniture Police, obnoxious co-workers, or even (and I wouldn’t wish it on my worst enemy) commercial radio. <shudder/>. For the purposes of this article I’m going to assume these inconveniences are more-or-less evenly distributed across the P set, with no net disadvantage to C++ projects.

Now in case I haven’t sprinkled this post with sufficient disclaimers of subjectivity, let me make one more. This is all based on my experience of the developer job market, mostly here in Sydney. Your experience and opinions may differ, and good luck to you if they do.

The Rise and Purge of C++

C++ itself used to be fairly evenly distributed across the P set. There was a time when it was just the default language and, despite the compiler writers valiantly struggling to keep up with a rapidly — and imaginatively — evolving standard, it was still widely used on all types of P projects. Especially the B projects; C++ and its enterprisey friends like CORBA were the way that we sexed up our data-centric applications back in the mid-90s.

Then Java came along and everyone who worked on B projects got swept along with it. At the time Java seemed like a huge step forward and allowed us to soar to dizzier heights of architectural astronautics. All that CORBA, SOM, COM and other nonsense would be re-invented in Java land, this time with a vague chance that it might work. For whatever reason it seems that the I projects were less affected by the Java bombshell (or by mixed metaphors, for that matter).

So fast forward to the present day, and we have all sorts of dreary jobs hewing enterprisey architectures out of raw Java, or C#, or even VB.NET, whatever the hell that is. C++ is yesterday’s news. The only projects still using it are, well, projects from the I set. Or, Dog help them, some projects still lumbering on from the 90s. You probably don’t want to work on one of the latter, but you almost certainly do want to work on one of the former. Being able to tell the difference is obviously a pre-requisite before putting the C++-has-best-jobs idea into practice.

C++ : It’s Not That Bad, Really

At this point you may well be thinking “well, C++ may be common amongst interesting projects, but only a few years ago you could say the same thing about FORTRAN, and I’d rather gouge my eyes out with a novelty mousepad than have to gaze upon code written in either of those languages!” And I sympathise with regards to FORTRAN, but modern C++ should not warrant such a reaction.

In 2001 a chap called Andrei Alexandrescu published a book called Modern C++ Design. Despite the ominous inclusion of “modern” in the title (to me that word always seems to denote the anachronistic), it was really groundbreaking and is still highly recommended reading. Alexandrescu showed the potential of the so-called generic programming style, which is enabled only when you have a truly powerful (albeit sometimes arcane) template system.

To those who, like me, struggled to use the early incarnations of generic programming, such as exhibited in the Standard Template Library, the book was something of a revelation. Today, the Boost libraries are enabling these idiom changes and in some cases going way beyond the potential glimpsed in Modern C++ Design. The result is that small-m modern C++, as exhibited by Boost itself, isnothing like the C++ of yore.

C++ has a bit of a bad reputation (as per the Linus quote above), and it is sometimes justified, but too often online I see noses turned up at C++ in favour of cooler dynamically-typed languages like Perl, Python and Ruby. But maybe this is based on an outdated perception of the C++ language, at least as it is practiced today, because you certainly can use dynamic typing in C++, for one thing.

I think it’s fair to say that if you were designing a better C from scratch these days, you probably wouldn’t end up with C++. But regardless of the mistakes made in the design of C++ — and I think the C++ Frequently Questioned Answers page captures most of them — I think the language has aged reasonably well. I’m certainly looking forward to C++0x, the next standard with many interesting features.

Spot The Ulterior Motive

To recap: there are many interesting projects in C++, and despite what you may have heard, it’s really not that unpleasant to code in.

So, go learn C++.

If you already know it, then good news! There are great jobs around. Who knows, if you email me, I may be able to help you find one.