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.
20 Comments »