The Tar Pit

Let us begin this discussion with the observation that I don't really know, as in know-know, how to program in C++. I can read the references well enough to get a clear grasp of the code that I'm analyzing or generating, I can easily spot certain design patterns, owing to my vast troves of knowledge gathered over at ye olde UPB -- but other than that, I'm not a master of C++, among the many other things I don't master. I find no shame in admitting that, and yet in admitting it, I must confess that I do know to a good extent how to program computers in general, and well enough such that each programming language looks to me like just another more or less consistent approach to process modelling. They're all Turing machines at the end of the day, aren't they?

Besides all that, I practice reading C++ code on a daily basis, which might not make me a good C++ programmer, but at the very least it makes me a pretty good C++ reviewer. The code that I get to visit may or may not be great, sure, but... fuck me, complain all you like, but I'm talking about code that took actual resources to produce, that sold and most importantly that has been used in great battles to keep technology going. I'm sure there's code out there that has seen much greater wars, and much of it was written in C++ or Java or some other language that I don't really like.

I don't like C++ because, in its initial being of an extension to a broken language (C), it inherited many of its ills. Moving forward from this core, the ISO C++ committee did not proceed to fix said ills, but rather they produced successive workarounds in the form of syntactic sugar sprinkled with some actually useful items, but regardless, all of these contributing piece by piece to the gigantic complexity of the language, and of its standard library. And that in itself is not so tragic -- complexity we shall have, but when this complexity lies hidden in the most subtle of spots and/or under piles of abstraction, it's really going to end up biting folks in the ass.

One can easily pick a close example that reminds him or her of the battles in keeping large C++ projects afloat: the object oriented model, as neat as it finds itself, tends to encourage the younger programmers to over-compartmentalize. They will try to encapsulate each and every small functionality into its own class, which certainly comes from the fundamentalist idea that everything and its subdog is an object, and that this will usher in a golden age where each tiny object is composable with another, a sort of destructuring applied in the field of computing. This misguided idea leads of course to unmaintainable piles of mess, if only by virtue of the "classes", i.e. of the abstractions, being mostly meaningless. Quite a misdesign pattern indeed!

And yet with all its faults, C++, revision 24 or whichever's in fashion nowadays, continues to endure. I may not like it, but it's the language some guys used to write some code way back when I was a wee kid, and if said code falls in my proverbial lap, I ain't gonna complain that it's not written in Common Lisp. Hell, even ye olde Bitcoin software is C++ with Boost and last I looked folks were using it irrespective of such petty considerations. At the end of the day, the same lies true of all old code, regardless of the "industrial" programming language it was written in, whether its name is Fortran, COBOL, Java or C -- I s'ppose the Linux users among you realize that retrofitting the kernel in Rust will take some amount of time in the order of man-decades, do you?

It's a fundamental property of software, this one: the more it ages, the better it turns out to be through its mere use. Conversely, once it falls apart, it falls into complete disuse.

Filed under: computing.
RSS 2.0 feed. Comment. Send trackback.