The Skeptical Methodologist

Software, Rants and Management

C++ is a horrible language

The title of this post was shamelessly ripped off from this wonderful diatribe.  But first, some context.  I work with a bunch of electrical engineers and other guys who’s sole knowledge of programming is Fortan.  Speaking of which, I am excited about the Fortran based language, Fortress, which Sun is developing, I think.  Fortran was, and still is, good at what it originally was meant to do – translate mathematical formulas( FORmula TRANslator).  Tacking on objects in the 90’s was like hooking up those two friends of yours that are just SO alike, they’d be, like, PERFECT for each other.  And sure enough, the few dates they went on were boring, awkward, and you got all the blame.  Sorry Grant.

Anyway, where was I?  Oh yeah, Fortran.  Fortran is incredibly simple and if it’s your only language, simplicity is the goal.  You begin to learn code as simply being nothing more than certain steps, to take in an established order.  Practically the only real metric of how well you code in Fortran is hacks and tricks for efficiency, which is all made worse by the language being so low level in the first place.  To sum it up, the double E’s I work with are obsessed with efficiency.  They couldn’t tell Big Oh notation from Asshole notation, but if you accidentally make an extra copy of an integer, boy, they’ll be explaining to you how you don’t know shit about software.  To sum up, I’m used to having conversations explaining the importance of object orientation, generic programming, ‘scripting’ languages, and the like to people who’s only way to judge code is how fast it runs.

I was suprised to hear this kind of talk from someone I regard as a pure software person.  There is no doubt about it – efficiency is incredibly important in programming.  Speed is important.  But we now realize that it isn’t the most important thing – maintainability is important.  Reducing defects is important.  Rapid delivery is important.  To deal with these things, we’ve demanded from language more and more complicated constructs like objects, modules, first class functions, and the like.  That’s why when someone condemns C++, even implicitly, because it’s a hair’s-width slower than C, I feel like they’ve missed the point.  But when they start claiming that a rats nest of function pointers is more maintainable and elegant than an object model, I’m really confused.

Don’t get me wrong.  If you were to propose writing an OS in C++, I’d think it was an interesting research project, but I wouldn’t expect delivery any time soon.  C is, was, and always will be the language for building kernels.  If you’ve read anything about domain specific languages, you’ll agree that most problem domains are better solved using a domain specific vocabulary, and it’s the developers job to turn that domain language into actual executable code.  Well, the DSL for kernels is C.  It’s domain is interfacing with computer hardware and memory, and it does it incredibly well.

But a revision control system?  This is something I still don’t understand.  I’m impressed by git, but only because it was the first time I had heard of a distributed version control model.  I guess I’m on airplanes and aweful lot, huh, and just HAVE to get to work at 40,000 feet?  Not really, but the distributed model simply seems more elegant given the use cases for a version control system, and quite honestly I think we’d all do a bit better if we branched and merged a little more.  Linus can implement Git in whatever language he wants to.  He can do it in brainfuck for all I care, I’m just a user.  But he’s lying to himself if he believes he chose C and Perl because they were the best tools for the job, and not just because they’re the tools he’s most used to.

I don’t want my DVCS running ass slow, but quite honestly, speed isn’t what I’m after either.  I know about Git, and am interested in it, but I still use subversion for my own personal projects.  I use it because it’s integrated with the tools I use, and frankly, I don’t want to screw around with having to learn the ins and outs of yet another tool.  I believe in time tool support for various distributed systems will be more widespread, but until then I’m stuck with subversion.  And despite all my complaints, I’ve never once even considered the speed.

Believe it or not, speed is not my number one concern with version control.  That concern is, and I suspect it’s everyone else’s too, correctness.  My version control better NEVER, EVER lose information I’ve committed to it.  That’s the point.  So is speed important after correctness?  No, usability is what is important to me after correctness, as I’ve described above.   Is speed third?  No, cost is third.  Thankfully, there’s a plethora of free options.  Speed and efficiency are number 4 in my list of things I need in a DVCS.

So if correctness is my most important requirement, which language would I prefer to code in – C or C++?  C++ hands down.  It’s more type safe via its better casting mechanisms and templates, RAII is a godsend, and exceptions are a better way to ensure errors are detected and dealt with rather than return codes that people can ignore.  What about usability?  Well, the two languages are on more even ground here since just about EVERYTHING has an interface to C code, but luckily most of them work with C++ with very little fuss.  In addition, since most people criticize C++ for letting programmers overdesign to easily and produce an API when one isn’t needed, I suspect that this is actually useful for extensibility and therefore usability with third party tools.  The two languages add equal cost (free) in and of themselves.  Finally, when it comes to speed one might be tempted to finally pronounce C the winner.  But given the fact that C++ isn’t, honestly, that much slower than C and the fact that your greatest bottleneck in a version control system tends to be a network, I’d say there’s no clear winner.

In other words, if I were to write a DVCS, I’d come armed with C++ and Python, not C and Perl.  But I’m not criticizing.  Linus is the one who’s thrown the first stone here, and although I’ve  made a point of saying he’s lying to himself if speed were the real reason he chose C for git, for good measure let’s see if he has any real criticism of C++ worth acknowledging.

Firstly, he says C++ sucks because he doesn’t like the programmers who use it.  Fair enough.  C++ is too ‘expert friendly’ as Bjarne himself has said, and many of those who think they can code in it probably shouldn’t.   But you also have to take into account that C is becoming one of those ‘revered’ languages, ala Lisp, that only attract people who are pretty smart in the first place.  In other words, a decent C++ programmer can perform as well as or better than a decent C programmer, and there are more decent C++ programmers, but far more terrible C++ programmers to sample from.  Either way, this doesn’t really amount to a good criticism of the language itself, and moreover, Java has been, thankfully, stealing most of our terrible C++ programmers.

Secondly, he argues that C++ programmers overly rely on the ‘crappy’ STL and Boost libraries, which are apparently not portable nor efficient.  If we’re talking base memory management, nothing is faster than a primitive array.  But given the correctness guarantees I can much more easily get with the STL, and the fact that they are not that much slower, the STL is a better bet.  Good programmers write, great programmers steal.  It’s a fallacy to believe that you can build a better vector, even if you’re the creator of Linux.  If you can, please do, and share it with the rest of us.  Most of the efficiency gains one gets from specializing list, hash and algorithm code by rolling their own is lost in the world of templating anyway.  It’s just not worth your time.  Furthermore, insofar as portability is concerned, I’m not sure if we’re in the early 90’s or not.  Templated code has been easy to compile since at LEAST the turn of the century.  Boost may not be portable to everything, but its at least as easy to port as C – for example, I don’t have to switch threading libraries with Boost::Thread.  Portability was the point.

Finally he brings up the efficiency argument, which frankly I just don’t understand.  Why is he considering git something that requires system level efficiency down to the very last bit?  Why didn’t he just write the damn thing in assembly if he were that obsessed.

It all boils down to git was never designed to take user’s needs into mind.  It was designed to download Linux source as fast as possible, and I’m sure it does that well.  The problem is if git fanboys and Linus want to go around advertising their system as the superior one, they might have to actually start listening to these ‘users’.  If he wants to build something for himself, as his own personal tool, then why not use the language he’s most familiar with?  But if he wants to build something that the programming community as a whole should use and enjoy, then he needs to stop pretending he magically shits bricks and every design decision he makes is the best one.  Choosing C for a project he expects others to adopt, maintain and extend was a bad one – it was one he made for himself, and which he’s continuing to justify by holding on to shreds of an early 90’s fear of a new language.


December 17, 2008 - Posted by | Uncategorized


  1. I’ve stopped at “kernals”…

    Comment by black | December 18, 2008 | Reply

    • Fixed.

      Comment by austinwiltshire | December 18, 2008 | Reply

  2. The problem of coding Git in C++ was talked about at least twice on git mailing list:

    I think the main reason why Git was coded in C, and not for example Python is that Linus Torvalds who wrote initial version of it knows C best. Add to this the fact that Git is filesystem at core (if special one), and at beginning it wasn’t much more than this; and I think you agree that for writing filesystems C is well suited.

    As to issue of performance: if a command takes minutes or at least tens of seconds you would use very different workflow than if a command takes a fraction of second. And Linus goal was few patches per second.

    Comment by Jakub Narebski | December 19, 2008 | Reply

  3. By the way, there is JGit, which is *reimplementation* of Git in Java (not complete, though).

    Comment by Jakub Narebski | December 19, 2008 | Reply

  4. Taking your argument a bit further, I’d suggest maybe you want to build a DVCS in Haskell – you get far more type checking than C++, and I’d suspect you’d be able to get a lot more work done in fewer lines of code, a maintainability win too. Or maybe OCaml or F#, they’re just as fast and quite portable too! Python is a pretty good choice too, I suspect you’d get excellent performance/portability by writing 99% of your in Python and a few things in C/C++.

    My point is, people don’t always make these decisions rationally, and any attempt to claim otherwise should probably be taken with a good helping of skepticism.

    Comment by fundae | December 21, 2008 | Reply

  5. “… the fact that your greatest bottleneck in a version control system tends to be a network…”.

    Uh, the big goal of any sane DVCS (the D in DVCS) is to minimize network access. It’s hardly the biggest bottleneck.

    “…So if correctness is my most important requirement, which language would I prefer to code in – C or C++? C++ hands down. It’s more type safe.”

    The safety of a strong typing system is so tiny in whole correctness issue of a DVCS which involves things such as: authentication, digital signature, etc. Keeping all the algorithms correct makes the type-safety issue almost irrelevant. And the what type-safety will give you if most important correctness-related operation was getting a void* from mmap() and feed that void* to SHA1()?

    “…It’s a fallacy to believe that you can build a better vector, even if you’re the creator of Linux. If you can, please do, and share it with the rest of us. Most of the efficiency gains one gets from specializing list, hash and algorithm code by rolling their own is lost in the world of templating anyway. It’s just not worth your time….”

    Uh, this is irrelevant, the main issue with STL and Boost is they’re getting in-the-way. In the middle of the hot-path, you really want to know exactly what’s the shape and form of the data-structures, what the exactly the code will do and not some abstract concepts. IOW, in performance critical code (code that will execute several million times), cache-friendly data-structure and code will leave STL and Boost to eat dust.

    “…Boost may not be portable to everything, but its at least as easy to port as C – for example, I don’t have to switch threading libraries with Boost::Thread. Portability was the point…”

    Again, in a DVCS, the underlying OS and FS is more a difficult portability issue than … thread library! How to efficiently handle NTFS vs EXT3, how to handle the lack of mmap(2) on Windows, how to handle slow stat()… are all more difficult than.. wrapping the thread API.

    “…Why is he considering git something that requires system level efficiency down to the very last bit? Why didn’t he just write the damn thing in assembly if he were that obsessed…”

    Modern compiler is very good at optimizing, most of the times as good or better than hand-written assembly… PROVIDING you feed it OPTIMIZABLE code. You’ll have to look at a chunk of code as if you was the compiler. All the OOP abstraction will just get in the way and prevent the programmer from doing that.

    Comment by bogolisk | December 21, 2008 | Reply

  6. There is one huge problem with C++: the standard is not freely available.

    You have a huge number of developers basically writing code until the compiler accepts it without knowing whether it is standard C++ or something the compiler happens to accept.

    Comment by bazfoo | December 21, 2008 | Reply

    • What f*cking planet are you living on buddy? I feel sorry for the users (or god forbid, customers) of your code if that’s what you f*cktards are doing.

      Comment by Ryan Sharp | July 24, 2011 | Reply

  7. […] C++ is a horrible language […]

    Pingback by Git weekly links: 2008-51 « git blog | December 21, 2008 | Reply

  8. There are a number of kernels written in C++.

    Comment by NB | July 29, 2009 | Reply

    • And they are all awful pieces of shit.

      Comment by Ryan Sharp | July 24, 2011 | Reply

      • Absolutely.

        Comment by Greg Plitt | April 15, 2014

  9. You accuse Linus of forgoing the best tool to use what he’s familiar with, and then immediate launch into the fact that you’re sticking with SVN because that’s what you’re familiar with.

    Comment by NB | July 29, 2009 | Reply

    • Talk about a hypocrite. The guy plain and simple hasn’t got a clue. He’s just learned a thing or two, convinced himself he’s a genius and proceeded to rant about people who are vastly more talented than himself in order to score geek-points off them. Shame that the only people he’s likely to impress are the kind of retards Linus was referring to when he was bashing “C++ programmers”.

      Comment by Ryan Sharp | July 24, 2011 | Reply

  10. C++ is often more efficient than C; abstraction without runtime cost if you know what you’re doing.

    Comment by NB | July 29, 2009 | Reply

  11. The title of this post is true, the rest isn’t.

    Comment by asdawda | March 29, 2010 | Reply

  12. Arguing about choice of languages is rapidly becoming an exercise in bikeshedding.

    Linus has already written git in C and it’s working fine. The high level interface is very usable, the low level interface is very flexible. The data structures are very well considered and as a tool, git is secure and FAST. Most importantly, it’s an order of magnitude more useful at what it does than most other systems.

    So when was the last time you wrote something as well implemented and successful as Linus?

    You are just a bikeshedding, C++-loving idiot and nothing more.

    Comment by Ryan Sharp | July 24, 2011 | Reply

    • Come on, Ryan, Linus has become a wealthy celebrity. Anything with his name attached is going to get an extra boost.

      Comment by Jeff | August 5, 2012 | Reply

  13. Smh at the utter stupidity of the author.

    Comment by Greg Plitt | April 15, 2014 | Reply

  14. “Java has been, thankfully, stealing most of our terrible C++ programmers.”

    Laughing at the incredulous and randomly generalized statement. C++ is not a language – it’s a hotch-potch of abnormally fitting “features” that no one can agree how to use consistently, or indeed, safely. You sound like a bitter dinosaur who cannot adapt to using the best tool for the job at hand, having expended your minuscule brain into memorizing C++. I would say that your C++ skills themselves would be highly suspect when put to the test.

    Comment by Greg Plitt | April 15, 2014 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: