C++ is a horrible language, says Linus Torvalds

" The fact is, that is exactly the kinds of things that C excels at. Not just as a language, but as a required mentality. One of the great strengths of C is that it doesn't make you think of your program as anything high-level. It's what makes you apparently prefer other languages, but the thing is, from a git standpoint, "high level" is exactly the wrong thing. "

and

"And if you want a fancier language, C++ is absolutely the worst one to choose. If you want real high-level, pick one that has true high-level features like garbage collection or a good system integration, rather than something that lacks both the sparseness and straightforwardness of C, and doesn't even have the high-level bindings to important concepts.

IOW, C++ is in that inconvenient spot where it doesn't help make things simple enough to be truly usable for prototyping or simple GUI programming, and yet isn't the lean system programming language that C is that actively encourags you to use simple and direct constructs."

In his "I'm a bastard" post to the linux kernel thread in 2000, he lambasted people arguing for a kernel debugger. His argument, clear as day, says he doesn't want to work with people who depend on the debugger , he wants people to understand the code as a whole.

"Oh. And sure, when things crash and you fsck, and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger.

Quite frankly, I'd rather weed out the people who don't start being careful early, rather than late. That sounds callous, and by God, it is callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's Darwinism in software development."

Here, 7 years later, he applies much the same argument to C++:

"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."

"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."

Call him a prick, call him selfish, call him egotistical, the bottom line is he's in charge of a product that is much bigger, more complicated, diverse, mature, and successful than the majority on the planet. Smart hackers will get past their emotion and understand his principles are sound, proven, and successful.

- Sometimes you really do need to write systems software. In these instances, I'm still going to use C++. I won't claim that C++ is a great language, but at the end of the day, the benefits provided by C++ make it worth it. It would just be more footwork in C. Classes, RAII, STL, templates, type-safety are all worth it. But this is because I have already made all the mistakes and written lots of bad C++ that I'm now able to write clean, simple and elegant C++. I'd advise a newbie programmer against becoming a C++ expert. It's not worth the time and effort to learn all the stupid cases and to learn when to use which feature and to what degree to avoid falling into the swamp of C++. It's worth knowing C++ well enough that you can hack systems code though. I wouldn't say "only learn C and not C++ for systems hacking!"

Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.

[NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)]

Interviewer: You're kidding...?

Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?

Interviewer: You bet I do, that's what I used to do.

Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.

Interviewer: I don't believe you said that...

source: http://members.safe-t.net/jwalker/programming/interview.html

He is telling the whole world that "Hey, here I am, you know, the guy who created the linux kernel, the best designed piece of software in the whole universe(don't listen to Tanenbaum though, he didn't learn OS fundamentals), so you better listen to me when I say that C++ _sucks_. Don't give me the BS about how so many large applications have been created in it, because they would have been only better had they been created in C(it's a magical language btw, solves _all_ your problems in the blink of an eye). If you go and read about people like Stroustrup, Sutter, Alexandrescu, Koening, Thomas etc, take it from me that they missed lot of their CS clases, so they don't know a thing about programming. How do I know? They use C++!"

Sage Linus at one point or the other has to wake up to the fact that he is not the guru of all things that is programming and his opinion of the C++ language is taken as seriously as that of my hair dresser.

In classical imperative programming (e.g. C, Algol, Fortran, Pascal, and Basic), procedures contain and copy data structures. The heap primarily exists when unusual flexibility is needed, e.g. when the number of data objects you need isn't known until runtime. so you manage them with a global heap-based collection. Generally, you try to avoid using the heap, and where you must use it, you build an API around your collection to hide the nasty ugly details.

Compared with imperative programming, object orientation provides a kind of inversion of control. Instead of having procedures which contain and manipulate data structures, you have objects which contain methods (to handle the messages that other objects send it). Objects manage their own lifecycles and storage allocation. This sort of distributed control implies a level of abstraction well above concerns about storage management. Instances of subclasses tend to be larger than instances of their parent classes, but so users of these polymorphic objects are presumed to be above worrying about the storage they take up. But that makes us dependent upon that nasty heap -- is it any wonder that the vast majority of object oriented languages _presume_ automatic garbage collection?

The very fact that the C++ programmer is responsible for storage management implies that C++ objects are not to be visualized as independent and cooperating entities that manage their own lifecycles -- because then it becomes unclear as to who will have responsibility for cleaning up.

Systems programming is of necessity low-level; a reliance upon automatic garbage collection simply isn't appropriate for those kinds of problems. Therefore, instead of trying to add object orientation to C (and therefore an over-reliance upon the heap), I think we'd have been better off to begin by simply adding a strong, polymorphic type system. Then we could write systems programs with a manageable degree of genericity, without requiring every programmer to become a language-lawyer interpeting seemingly conflicting regulations, or an empirical scientist running experiments to determine what his programming language does in a given situation.

If we could then create easy hooks by which an object-oriented language could make calls to low-level subroutines written in that systems programming language, so much the better.