Here's more ammo from Linus (2010). He explicitly articulates that communication is the most important thing and that C is "a largely context-free language" which is a huge boon for large projects like the kernel.

http://www.realworldtech.com/forum/?threadid=104196&curp...

Couldn't resist posting my favourite OO quote again!

I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project. Programmers have been conned into using all these different programming languages and they've been conned into not using easy ways to connect programs together. The Unix pipe mechanism-pipe B pipe C-is trivially easy to connect things together. Is that how programmers connect things together? No. They use APIs and they link them into the same memory space, which is appallingly difficult and isn't cross-language. If the language is in the same family it's OK-if they're imperative languages, that's fine. But suppose one is Prolog and the other is C. They have a completely different view of the world, how you handle memory. So you can't just link them together like that. You can't reuse things. - Joe Armstrong in Peter Seibel's Coders at Work: Reflections on the Craft of Programming

Why code in C++ anymore?

I don't know C++ and its community very well, but here are my suspicions. I'd love for someone to confirm or dispel them.

* Relative to C is obviously that it provides a greater toolbox.

* Relative to Java, it gives more fine-grained control of the target platform, and programs have somewhat better startup speeds (though still often not very good, which I again suspect is because of large binary sizes).

* Relative to Python and Ruby, its static typing gives better guarantees as it allows less to fail at runtime.

* Relative to Go, Rust, D and ML languages, it is more well-established. Especially regarding GUI toolkit libraries.

"The computer benchmarks hosted on Alioth, for example, show that C++ (running on 32-bit Linux) runs the series of tests 27% slower than C. Other surveys show this difference as slightly larger or slightly smaller."

I don't know how they can make this conclusion. I'm not even sure what it means when they say that "C++ is 27% slower". In the C benchmarking code, they hand roll a lot of the data structures whereas in the C++ code, they include either the standard library or boost. So it's not really a comparison of C vs C++ is it. There is nothing about C++ that would make that big of a difference.

>> I'm not even sure what it means when they say that "C++ is 27% slower". <<

It means the author mis-read "how many times slower, ..., compared to the fastest programs."

Compared to the fastest programs, not compared to the C programs.

Compared to C programs, and Ada programs, and C++ programs, and JavaScript programs, and Fortran programs... that were faster.

I haven't looked at the benchmark, but I'd assume that the comparison is supposed to be "idiomatic C" vs "idiomatic C++".

Possibly, but as they present it, it makes it seems as if there was something inherent that would make it so much slower.

Well, for a long time the STL string class had poor performance. Idiomatic C++ would use the STL string class. Therefore idiomatic C++ would suffer a performance penalty.

27% slower = what one program does in 1 unit of time, another program requires 1.27 units to do.

Well... I code in C because I am working on embedded systems, where power and clock cycles are very precious.