random memes }

Linus is a bit of a jerk

... from a somewhat emotional discussion ... C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Apparently Linus is not a very good programmer - and by extension thinks no one else could be - when using C++ as a tool.

Sounds familiar. Heard the same sort of rants out of ego-laden assembly language programmers dismissing higher level languages (C or Pascal) back in the early 1980's. Makes as little sense now as it did then.

C++ is an extension of C. In every way C is good, C++ is exactly as good, and some large ways C++ is better. C++ is a dangerous language (as is C), just as a knife is a dangerous tool. (I keep the knives in my kitchen very, very sharp.) A mediocre programmer can write very bad code in C++. A good programmer can write clean and hideously efficient code in C++. For a good programmer C++ is always and without exception a better tool than C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

  • infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
  • inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

The last bit I will agree with somewhat. I played a bit with STL and Boost - enough to form an opinion - but never in code that shipped to a customer. Not so much that I am convinced either library is necessarily bad, rather more that I am not convinced those big gobs of code are all good enough for my purpose. Digging into the code for large libraries, what I usually find is a mixed bag. Some of the code is quite good, but not all.

I very often write my own string, list and hash classes - none of which are difficult to write. There is very often some aspect of the problem to be solved that benefits greatly from a tweaked implementation, and the same end result is just not possible with a general purpose implementation. Often I can re-use a bit of prior work, with adjustment to fit the problem at hand.

There are parts of the C++ language which I do not consider well done. Trying to throw new features into a language during the standardization process is an amazingly bad idea - and the C++ standard is a good/bad example. (In contrast I believe the Standard C folk did an outstanding job.) Templates in particular do not seem well thought out. I do use C++ templates, but seldom. Not really a problem - just use the good bits.

There is another problem - excessive abstraction - common with C++ and Java programmers. As a group, Java programmers are especially prone to this excess. Note that I blame the programmers, not the language. There is nothing in either language that prevents writing efficient and clear code, but the ease of adding abstractions does make it possible for an incautious programmer to build things more complex than they can understand.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

This is nonsense. The problem is with the programmers, not the language.

C++ is dangerous in the same way that a sharp knife is dangerous. Used with insufficient skill or caution and you can do a lot more damage. Used well and you can get a lot more done.

Now if Linus were to say that the skill levels among the large group of Linux contributors is quite various, and not all are skilled enough (or able to be managed) to produce good C++ code ... then he could have a good point.

Along the same lines ... as a decoy I keep a block of gift knives (cheap steel, serrated edges, not very sharp) in plain view on the counter in the kitchen. The good hideously sharp knives are out of sight in a drawer. A guest in the kitchen is going to grab the gift knives, and so are somewhat less likely to get into trouble.