Linus on C++ (2007)
article.gmane.org
article.gmane.org
Furthermore, and more on topic: Linus is a great coder, there's no doubt about that. But he's a terrible front-man. The response is unnecessarily inflammatory and is also appalingly arrogant.
C++ has its place. Even though I, personally, prefer C over C++, I think C++ could have even had a place in the Linux kernel. Particularly, I think the whole File System interface could have been simplified if it were written in C++ instead.
I'm really tired of the arguments of X language > Y language. Languages have different purposes. There are times when C++ makes sense, times when C makes sense, times when Perl makes sense and times when Python makes sense. It's time to stop evangelizing about our tools. Nobody argues that a hammer is better or worse than a screwdriver.
That attitude is precisely why a lot of our tools, including programming languages, are crap. It's nice, warm and cozy in the world where no language is better than other, but that world is mostly populated by mediocre programmers.
Yes, there are times when language A makes more sense than language B. Especially because when we talk about languages, we're also including the libraries and runtimes that go with them. Here's a ridiculously exaggerated example: ActionScript makes more sense than Lisp when you're developing Flash applications. That is (mainly) because Flash has no support for Lisp at this moment, although you could write your own Lisp compiler for AIR.
To use a real world example, C is a lot better match than Java when you have to process an input file with a size of several gigabytes (should be crossing the terabyte boundary nowadays), which contains descriptions of polygons that you have to fracture into smaller primitives (rectangles and trapezoids) and write out a resulting file containing those primitives in a format understood by a specific piece of hardware designed to process it; and you have to do it in a very limited amount of time which keeps shrinking with every version you release to your client.
The point I'm making here is that, for most languages, there are circumstances that make a language X the best fit, or at least a better fit than most others. If language Y is the best fit under a set of circumstances that is a lot more narrow than the set of circumstances that makes language X the best fit, then I'll tend to say that "X language > Y language", at least "most of the time". For me, C++ is one of the languages that end up near the bottom of that list, because the circumstances under which I would choose it instead of any other language (such as D, for example) are extremely narrow.
Also, I think people want to attract others to their tool of choice due to the positive network externalities involved.
This is huge point. I've wasted so much time in my life fighting about what technology to use on a project- with people that aren't actually going to be writing any code on the project. Why do people care SO MUCH about what technology is used on project- even when it's a project they are NOT ON? Positive network externalities sums it up pretty well.
The crazy thing programming is that it defines people's mental models around problems. The common chestnut of Java programmers using iterative techniques in SQL stored procedures, as opposed to set based operations is borne out in reality. The different mental models associated with different languages make it hard to switch too often.
To use your examples: why learn Erlang? Well, if your concurrency needs are great enough, Erlang is a great fit! If not, maybe consider another language? You pick the best and most appropriate tool for the job. Sometimes you can nail something in using your shoe, but more often than not, the best tool is a hammer.
Why learn Ruby if you know Python? Perhaps you have a project that could be taken to market significantly faster if you use Rails? Perhaps you can use Django? It really _is_ a question of the right tool: and sometimes that tool is Ruby and sometimes it's Python and sometimes it's Java (never COBOL :)).
You could probably make a strong case for any language out there. But you should make sure you're choosing the right one for your task: square pegs and square holes.
I think that's the whole point of his response. For GIT, C++ is a terrible choice. I think he's pretty explicit about this:
"So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake."
He makes some good points, but they could have been made a in a better tone, which makes him a terrible front-man.
linus torvalds c++:news.ycombinator.com
and you'd have found the previous threads, but that's just inconvenient enough that I bet people don't do it as often as they could/should.
However, submissions are often slightly different or seem to be redirected from blogs, etc. So it'd still be nice to have a way to add a duplication tag.
Meanwhile, lots of high-level alternatives are getting better and are becoming more and more suitable in more places where C++ once reigned, so as C++ programmers get experience in more languages, the blub paradox is no longer keeping us as happy.
I work in games, and I don't see C++ going away anytime soon, though other languages are getting more and more use even now. But C++, as a language, is painful to use, especially when it's as restricted as it is for performance and portability reasons.
It does not seem like C++ is on top of the priority list for Microsoft.
Same with the XBox: serious development is done in C++.
On the evidence of this article, he's a guy who likes to make ad hominem attacks, unjustified generalisations, and unsupported (and demonstrably wrong) accusations based on proof by raw ego. This much is obvious to numerous people who actually use C++ to do the sort of things Torvalds criticises.
C++ has plenty of flaws, to be sure. And yes, it's being steadily overtaken by newer tools for many purposes, too. But Torvalds didn't make a reasoned argument based on those things. He wrote a rant, and not even a very good one.
As far as I can tell, everything Linus writes that sounds like a provocative "religious" statement about programming is really just a statement about his world of Kernel development. He just isn't concerned about with other space so "C++ is a horrible language.." yes, for Kernel program, sure.
As for a serious industry where C++ is not going away soon, virtually all major game titles, even on consoles with restrictive memory limitations, are written in C++ for performance reasons.
What language drives the inner loops at Google? C++. Google is famous for being driven by best practices, so if you're doing a lot of C++ coding, you might want to take a look at the Google C++ style guide.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
Priceless.
Both hg and bzr also use multiple languages. Both use C and python. With the C part used for parts that need speed, and the python for the prototyping and also as an implementation language.
In amongst the snark, this seems insightful.
GUI oriented OS might as well be C++... Alpha released yesterday - so maybe the C++ bashing is good timing. We'll see what happens.
[edit] Checking my assumption. "The BeOS is a C++ application framework, so your source code will be written in C++ and saved in source code files that have an extension of .cpp." via http://www.haiku-os.org/legacy-docs/programming_the_be_opera...
and "Haiku is developed in C++ and provides an object-oriented API." http://en.wikipedia.org/wiki/Haiku_%28operating_system%29
I can certainly imagine, and have seen, some insane C++. But, there are things in C++ that even a kernel developer could love.
Probably the simplest example is constructors and destructors. They are a useful for writing clean setup/teardown blocks, and allow data structure initialization errors to be completely avoided. Sure, you could put horrible things into constructor code, and use 10 levels of multiple inheritance to create constructor hell; but if you don't do that, it's really not that magical.
It seems that Linus resists many avenues of investigation that might in the long run benefit kernel architecture.
What makes you think that STL would be a good choice for the kernel?
OH WOW THEY RELEASED. Today! Sweet! happydance
(the fine print: technically, Haiku isn't quite BeOS, it's a re-implementation of BeOS.)
Indeed. It often boils down to the quality of the programmer rather than the quality of the language. Community is everything.
"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."
Even as a C++ fan myself, I can't argue with that.
"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"
Not in my experience. But the Linux kernel has stability and portability demands far beyond nearly anything else out there. So he's probably right. For his domain of experience: the kernel.
"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."
He's not arguing against C++, he's arguing against abstraction. It's the silliest part of his essay.
"So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage."
Good god. He sees C as appropriate for something like git? Sure, I'd use it too if my programming team was expert in C and nothing else. That doesn't say anything about the appropriateness of the language.
"If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess."
He's probably right. There's something about the real language fanatics that often limits their rational planning facilities. They make poor project implementors, even though their language expertise makes them good programmers in the trenches. My guess (not ever having heard of Monotone) is that this is what went wrong with the project.
Then again, as a git user, I have one critique of Torvalds' C project: doesn't anyone working on the project have any conception of usability? Git is way too easy to use improperly and often hard to use correctly. It feels like it was coded by a bunch of C-language kernel-hackers. Which it was.
Ironically, STL and Boost are much more portable than Git.
Considering one of the primary goals of Git was to be faster than greased Jesus with a tailwind, yeah, C's an appropriate choice. Trading more expert programmer hours for fewer CPU cycles is something C does very well.
No; as the snippet you quoted already makes clear, he's arguing against inefficient abstraction, which I take to mean abstraction that introduces bottlenecks into a program and is hard to change without rewriting the program. That is a very real problem and not silly at all.
A small subset of the STL written for the kernel would do wonders (e.g. vector and list).
Yes, I'm sure that he's for perfect abstraction, as is everybody else. But he seems to be arguing against real-world abstraction which is what we've got. All abstraction introduces inefficiencies. There is no magic bullet.