4 ms·

This rings hollow. It's like saying "C++ feature X can go horribly wrong when used without adult supervision, therefore C++ is unusable." This is especially s

This rings hollow. It's like saying "C++ feature X can go horribly wrong when used without adult supervision, therefore C++ is unusable." This is especially silly coming from someone who favors a professional stunt language like C. If somebody uses too much overloading, reject their patch. If somebody makes a template tarpit, abuses operator(), or gets too fancy with operator overloading, send it back to 'em. Context dependency bad? I like having the superclass define a contract so that you can ignore which subclass is being used. And C++ even rubs your nose in the name of the superclass, to avoid duck typing (which Python/Ruby use with near impunity anyway). Polymorphism also gives you what amounts to functional programming without touching C's awful function pointer syntax. I suspect a lot of Linux code uses baroque switch/case or "if" statements just to avoid the pain of function pointers. Edited.

jafl5272 16y ago
I'll deal with this in order of decreasing insanity: 1) Polymorphism is NOT functional programming. Using function pointers, which you seem to detest, is one aspect of functional programming. If you've only used C++, then you don't know what you're missing from languages like Lisp or JavaScript. (I should know. I was once like that.) 2) I seriously doubt the Linux kernel avoids function pointers. Ever heard of dispatch tables? Good C hackers know that smarter data structures make for simpler code. 3) Any feature that can go horribly wrong will go horribly wrong when you have a large project with lots of contributors. Everybody who successfully uses C++ on a large project has a huge "coding standards" document to keep the project from crashing and burning. I know Google has it, and I've seen others, too. Even I have it for my own personal C++ projects! 4) What Linus meant by "context dependency" is that you have to know the object's type in order to know what the function will do and you even have to figure out which version of the function will be called, based on the arguments. This is hell when you get a small patch in the middle of a larger function.
- Daniel_Newby 16y ago
  1) You can pass around worker objects and apply them to things. 2) Declaring, initializing, and using dispatch tables requires a boat load of syntax, or GTK+ style macro hell. To the best of my recollection, Linux only goes to the trouble for a few large, complex subsystems, like networking and filesystems. Many other areas could probably benefit from it but cannot afford the price. 3) True. But once you climb the hill, you get to offload a lot of crap onto the compiler. Forever. 4) Linus already applies his +18 Axe of Correction to large functions and nesting depth. Anybody who reviews patches without a color-highlighting code browser deserves what they get.
dkarl 16y ago
I think his main point vis-a-vis C and C++ is that the kernel has a unified C culture and adding C++ would import a bunch of different C++ cultures. As a C++ developer in a C++ shop, I can appreciate this. Our shop has a very solid and consistent C++ culture. We can read each others' code because we all use the same language features and coding style. You can't do coherent C++ development without having this unity. The only way to develop a unified C++ culture for the Linux kernel would be for it to be grown slowly over time, starting from a small group of developers, the same way the kernel was. That can't and won't happen. If C++ is allowed into the kernel, a bunch of extremely skilled C++ programmers from different C++ cultures will start to contribute kernel patches written in C++, and it will be a tower of Babel. However, I don't buy his argument that C++ is unsuitable because it's linguistically a high-context language. Part of this problem of context is solved by having disciplined, humble coders who know the limits of human intelligence. (I do not think these are new requirements that would exclude existing kernel contributors. C has, and the kernel uses, macros.) Part of the problem is solved by having a unified culture. The rest of the problem of "context" in C++ is really what would be called "state" in C, and of course you can't read state in the text of a C program. If you could magically create a unified and disciplined culture of C++ usage in the kernel, it would be fine. But that can't happen, so C++ is out of the question.
- beza1e1 16y ago
  GCC is now allowing C++ code. It will be interesting how they can keep C and C++ style unified and coherent.
- Daramarak 16y ago
  Thanks, nice to read a sober judgment of the situation. As a both a C and C++ programmer I really appreciate your point. I would however argue that some effort should be done to enable the possibility to create some common culture. I am sure that some unbiased eyes could find subprojects where c++ (or other compiled oo/functional languages) would be better suited than c. I strongly believe that the paradigms all have their uses, and that in time the Linux project would be more powerful if it used the technology available. After all, isn't that one of the great strengths of openness?
eru 16y ago
> Polymorphism also gives you what amounts to functional programming without touching C's awful function pointer syntax. Which aspects of functional programming are you talking about?
- ajuc 16y ago
  Probably operator() and passing classes that have this operator implemented around. For me it isn't better than function pointers, also because of method - function distinction we have 2 different incompatibile kinds of functions.
  - eru 16y ago
    The operator() does not bring you any closer to functional programming. It's just syntactic sugar, maybe even nice sugar.
- Daniel_Newby 16y ago
  > Which aspects of functional programming are you talking about? Passing around things that do work on other things -- easy with C++ worker objects, painful with C function pointers (or worse, pointers to structs full of function pointers).

jafl5272 16y ago

I'll deal with this in order of decreasing insanity: 1) Polymorphism is NOT functional programming. Using function pointers, which you seem to detest, is one aspect of functional programming. If you've only used C++, then you don't know what you're missing from languages like Lisp or JavaScript. (I should know. I was once like that.) 2) I seriously doubt the Linux kernel avoids function pointers. Ever heard of dispatch tables? Good C hackers know that smarter data structures make for simpler code. 3) Any feature that can go horribly wrong will go horribly wrong when you have a large project with lots of contributors. Everybody who successfully uses C++ on a large project has a huge "coding standards" document to keep the project from crashing and burning. I know Google has it, and I've seen others, too. Even I have it for my own personal C++ projects! 4) What Linus meant by "context dependency" is that you have to know the object's type in order to know what the function will do and you even have to figure out which version of the function will be called, based on the arguments. This is hell when you get a small patch in the middle of a larger function.

Daniel_Newby 16y ago
1) You can pass around worker objects and apply them to things. 2) Declaring, initializing, and using dispatch tables requires a boat load of syntax, or GTK+ style macro hell. To the best of my recollection, Linux only goes to the trouble for a few large, complex subsystems, like networking and filesystems. Many other areas could probably benefit from it but cannot afford the price. 3) True. But once you climb the hill, you get to offload a lot of crap onto the compiler. Forever. 4) Linus already applies his +18 Axe of Correction to large functions and nesting depth. Anybody who reviews patches without a color-highlighting code browser deserves what they get.

dkarl 16y ago

I think his main point vis-a-vis C and C++ is that the kernel has a unified C culture and adding C++ would import a bunch of different C++ cultures. As a C++ developer in a C++ shop, I can appreciate this. Our shop has a very solid and consistent C++ culture. We can read each others' code because we all use the same language features and coding style. You can't do coherent C++ development without having this unity. The only way to develop a unified C++ culture for the Linux kernel would be for it to be grown slowly over time, starting from a small group of developers, the same way the kernel was. That can't and won't happen. If C++ is allowed into the kernel, a bunch of extremely skilled C++ programmers from different C++ cultures will start to contribute kernel patches written in C++, and it will be a tower of Babel. However, I don't buy his argument that C++ is unsuitable because it's linguistically a high-context language. Part of this problem of context is solved by having disciplined, humble coders who know the limits of human intelligence. (I do not think these are new requirements that would exclude existing kernel contributors. C has, and the kernel uses, macros.) Part of the problem is solved by having a unified culture. The rest of the problem of "context" in C++ is really what would be called "state" in C, and of course you can't read state in the text of a C program. If you could magically create a unified and disciplined culture of C++ usage in the kernel, it would be fine. But that can't happen, so C++ is out of the question.

beza1e1 16y ago
GCC is now allowing C++ code. It will be interesting how they can keep C and C++ style unified and coherent.
Daramarak 16y ago
Thanks, nice to read a sober judgment of the situation. As a both a C and C++ programmer I really appreciate your point. I would however argue that some effort should be done to enable the possibility to create some common culture. I am sure that some unbiased eyes could find subprojects where c++ (or other compiled oo/functional languages) would be better suited than c. I strongly believe that the paradigms all have their uses, and that in time the Linux project would be more powerful if it used the technology available. After all, isn't that one of the great strengths of openness?

eru 16y ago

> Polymorphism also gives you what amounts to functional programming without touching C's awful function pointer syntax. Which aspects of functional programming are you talking about?

ajuc 16y ago
Probably operator() and passing classes that have this operator implemented around. For me it isn't better than function pointers, also because of method - function distinction we have 2 different incompatibile kinds of functions.
- eru 16y ago
  The operator() does not bring you any closer to functional programming. It's just syntactic sugar, maybe even nice sugar.
Daniel_Newby 16y ago
> Which aspects of functional programming are you talking about? Passing around things that do work on other things -- easy with C++ worker objects, painful with C function pointers (or worse, pointers to structs full of function pointers).