6 ms·

Linus Torvalds on C++ (2007)

47 points by ruben94 11y ago

scrapcode 11y ago
This was seemingly discussed on HN 7.5+ years ago: https://news.ycombinator.com/item?id=51451 https://news.ycombinator.com/item?id=51451
- gavinpc 11y ago
  I'd go as far as to say that it was actually discussed. Meanwhile, I believe the submission guideline is to include the year (2007).
- M8 11y ago
  Let me jump into my time machine and join the discussion back then!
NeutronBoy 11y ago
It's only this time around that I've read the sad conclusion to this thread, from the original contributor http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 http://thread.gmane.org/gmane.comp.version-control.git/57643... > Unfortunately, I haven't had any time inte the last few days to code, nor read mail. I'm assuming that there is no point in me finishing the patch and that git will go with the strbuf solution? /Lukas ... with no response.
- uv3d779b 11y ago
  Typical Linus. Pretty much an opinionated ass, with very (very very) few of the positive connotations that come with being opinionated.
  - coldtea 11y ago
    >with very (very very) few of the positive connotations that come with being opinionated Yeah, only "getting shit done" and "getting Linux and Git" happen, which is pretty much all he attempted to do.
  - devnonymous 11y ago
    Typical Troll. Pretty much a flame-bait comment, with very (very very) few of the objective truths should that come with being a commenter.
vivaforever 11y ago
every once in a while, people bring this up.
Elv13 11y ago
> 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 opposite can also be said. By re-inventing a simple data structure, you can end up 2 years later in the same position where your structure is inefficient (list vs. array, etc) and you end up having to rewrite your app. While implicit operator overload was probably a C++ mistake, it does allow to replace some kind of structures with other one without changing the code relying on them. Other than that, I kind of agree that C++ is kind of terrible. So is perl, php, js or any other languages that send a barrage of features to the programmer without managing to educate them on their impact on performance and memory structure. Most C++ devs know about vTables and that's about it. I would also argue that C isn't a very good language either. It may be simpler to "get" what actually happen when you run your code, but has sub par code organization, total lack of "pointer flow" tracking, causing huge security traps and has an evil reliance on casting for any kind of structure/callback abstraction. All of those things could be "fixed" in new languages, but beside Rust, it seem there is no leverage for proper system level languages these days. OOP is probably a better choice for business programming anyway, but that's not even half of the market.
- gizi 11y ago
  Scripting languages are not meant to be fast. For speed, we have C. A script spends most of its time in its underlying C components anyway. Therefore, there is not even a need for these scripting languages to be fast.
  - Elv13 11y ago
    My comment wasn't about fast "scripting" languages, for whatever your definition of that is. I don't think stronger typing and memory constraint enforcement have anything to do with scripting languages. In my opinion, C lack them by design, not be necessity. A language could, in theory enforce them without runtime penalty and without losing too much flexibility (such as array aliasing). C++11/14 "auto" is an example where someone can have the equivalent of a void* with compile time type checking and "no" runtime penalty. Yes, multiple specialized version of the method will be created and increase the binary size and potential cache fault, but much of them will (ok, should...) be eliminated/combined again during LTO. A slightly incompatible fork of C could also remove array to pointer demotion, sizeof() would then be consistent and potential overflow would be possible to catch using branch analysis or -fsanitize=.
10098 11y ago
Still beating the dead horse, huh?
gizi 11y ago
I agree with Linus. C++ is too complex and overengineered, and taking in contributions in it for something like git, is a recipe for disaster. However, C in all its simplicity already has its potential for abuse. Macros can go very bad. Very bad. (Just look at openSSL). It is also not difficult to abuse the left-right rule in pointer arithmetic: *x->a->c=5. It can easily become incomprehensible. We did not need C++. We needed a way to further simplify C.
- StephanTLavavej 11y ago
  What's a left-right rule? Arrow binds tighter than deref, just like multiply binds tighter than plus. That's * (x->a->c)=5, just like how a * b * c + d * e * f works. C and C++ have some confusing precedence (famously, bitwise), but this is not one of them.
- fit2rule 11y ago
  >We needed a way to further simplify C. Lua is the answer. :P
- sacado2 11y ago
  Something like MISRA C ?
  - burstmode 11y ago
    Yeah, it's alway funny to see the reaction of fresh-from-the-mill CS-academics when they have to code in an MISRA regulated project for the first time. Around half of them quits after a month because they are unable to write 100 lines of working code without some babysitter (aka. garbage collector) cleaning up behind them. C++ started out as a great 'next generation C', but in the last years it became a playfield for CS-academics, just adding one useless esotheric feature after each other.
hieupm37 11y ago
There is no perfect programming language. Just choose what's perfect to solve your problem.
- shogun21 11y ago
  Or whatever's "good enough" to solve your problem.
M8 11y ago
"The fact is, git is better than the other SCM's. And good taste (and C) is one of the reasons for that." If he likes simplicity and good taste then why did he pick Git over Mercurial? Because he did not implement the latter?
- deleted 11y ago
  [deleted]
- fit2rule 11y ago
  .. because he actually understands Git, perhaps?
  - M8 11y ago
    That's not an argument, Bjarne Stroustrup understands C++, does it make it elegant or simple?
    - fit2rule 11y ago
      If you ask Bjarne, I'm sure he'd have a position that would be based on his understanding. Same as asking Linux about Git leads him to answer: it is elegant and simple. I think the question is, what makes reality - an individual opinion, or the mass-consensus? This is always a delicate question to ask.
fit2rule 11y ago
Everything I've ever wanted to be able to do with C++, I can do with Lua. I see it as the obvious progression from C - though I still find C a highly useful language. Putting Lua on top of whatever needs to be low-level, written in C, provides the next-generation toolset that I find so very productive.
sudeepj 11y ago
The fact that C++ is vast is well known. If a language supports some arcane things then it will end up in the code (even if its very less percentage wise). Because its arcane, most of the developers will not be able to deal with it effectively. Example of arcane: overloading comma operator.
jbandela1 11y ago
In the spirit of Greenspun's 10th Rule Any sufficiently complicated C program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of C++. For example: 1) Macros for data structures instead of templates 2) Virtual functions emulated with function pointers 3) goto fail instead of exceptions
rileymat 11y ago
My biggest problems with C++ (one of my favorite languages) 1. ABI issues. 2. Template Error messages. 3. Templates need be defined in header files (generally). 4. Object Slicing. 5. Cross platform Unicode/ASCII string encoding. I understand the reasons behind these, none the less they are really annoying.

47 points by ruben94 11y ago

This was seemingly discussed on HN 7.5+ years ago: https://news.ycombinator.com/item?id=51451 https://news.ycombinator.com/item?id=51451

gavinpc 11y ago
I'd go as far as to say that it was actually discussed. Meanwhile, I believe the submission guideline is to include the year (2007).
M8 11y ago
Let me jump into my time machine and join the discussion back then!

NeutronBoy 11y ago

It's only this time around that I've read the sad conclusion to this thread, from the original contributor http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 http://thread.gmane.org/gmane.comp.version-control.git/57643... > Unfortunately, I haven't had any time inte the last few days to code, nor read mail. I'm assuming that there is no point in me finishing the patch and that git will go with the strbuf solution? /Lukas ... with no response.

uv3d779b 11y ago
Typical Linus. Pretty much an opinionated ass, with very (very very) few of the positive connotations that come with being opinionated.
- coldtea 11y ago
  >with very (very very) few of the positive connotations that come with being opinionated Yeah, only "getting shit done" and "getting Linux and Git" happen, which is pretty much all he attempted to do.
- devnonymous 11y ago
  Typical Troll. Pretty much a flame-bait comment, with very (very very) few of the objective truths should that come with being a commenter.

vivaforever 11y ago

every once in a while, people bring this up.

Elv13 11y ago

> 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 opposite can also be said. By re-inventing a simple data structure, you can end up 2 years later in the same position where your structure is inefficient (list vs. array, etc) and you end up having to rewrite your app. While implicit operator overload was probably a C++ mistake, it does allow to replace some kind of structures with other one without changing the code relying on them. Other than that, I kind of agree that C++ is kind of terrible. So is perl, php, js or any other languages that send a barrage of features to the programmer without managing to educate them on their impact on performance and memory structure. Most C++ devs know about vTables and that's about it. I would also argue that C isn't a very good language either. It may be simpler to "get" what actually happen when you run your code, but has sub par code organization, total lack of "pointer flow" tracking, causing huge security traps and has an evil reliance on casting for any kind of structure/callback abstraction. All of those things could be "fixed" in new languages, but beside Rust, it seem there is no leverage for proper system level languages these days. OOP is probably a better choice for business programming anyway, but that's not even half of the market.

gizi 11y ago
Scripting languages are not meant to be fast. For speed, we have C. A script spends most of its time in its underlying C components anyway. Therefore, there is not even a need for these scripting languages to be fast.
- Elv13 11y ago
  My comment wasn't about fast "scripting" languages, for whatever your definition of that is. I don't think stronger typing and memory constraint enforcement have anything to do with scripting languages. In my opinion, C lack them by design, not be necessity. A language could, in theory enforce them without runtime penalty and without losing too much flexibility (such as array aliasing). C++11/14 "auto" is an example where someone can have the equivalent of a void* with compile time type checking and "no" runtime penalty. Yes, multiple specialized version of the method will be created and increase the binary size and potential cache fault, but much of them will (ok, should...) be eliminated/combined again during LTO. A slightly incompatible fork of C could also remove array to pointer demotion, sizeof() would then be consistent and potential overflow would be possible to catch using branch analysis or -fsanitize=.

10098 11y ago

Still beating the dead horse, huh?

gizi 11y ago

I agree with Linus. C++ is too complex and overengineered, and taking in contributions in it for something like git, is a recipe for disaster. However, C in all its simplicity already has its potential for abuse. Macros can go very bad. Very bad. (Just look at openSSL). It is also not difficult to abuse the left-right rule in pointer arithmetic: *x->a->c=5. It can easily become incomprehensible. We did not need C++. We needed a way to further simplify C.

StephanTLavavej 11y ago
What's a left-right rule? Arrow binds tighter than deref, just like multiply binds tighter than plus. That's * (x->a->c)=5, just like how a * b * c + d * e * f works. C and C++ have some confusing precedence (famously, bitwise), but this is not one of them.
fit2rule 11y ago
>We needed a way to further simplify C. Lua is the answer. :P
sacado2 11y ago
Something like MISRA C ?
- burstmode 11y ago
  Yeah, it's alway funny to see the reaction of fresh-from-the-mill CS-academics when they have to code in an MISRA regulated project for the first time. Around half of them quits after a month because they are unable to write 100 lines of working code without some babysitter (aka. garbage collector) cleaning up behind them. C++ started out as a great 'next generation C', but in the last years it became a playfield for CS-academics, just adding one useless esotheric feature after each other.

hieupm37 11y ago

There is no perfect programming language. Just choose what's perfect to solve your problem.

shogun21 11y ago
Or whatever's "good enough" to solve your problem.

M8 11y ago

"The fact is, git is better than the other SCM's. And good taste (and C) is one of the reasons for that." If he likes simplicity and good taste then why did he pick Git over Mercurial? Because he did not implement the latter?

deleted 11y ago
[deleted]
fit2rule 11y ago
.. because he actually understands Git, perhaps?
- M8 11y ago
  That's not an argument, Bjarne Stroustrup understands C++, does it make it elegant or simple?
  - fit2rule 11y ago
    If you ask Bjarne, I'm sure he'd have a position that would be based on his understanding. Same as asking Linux about Git leads him to answer: it is elegant and simple. I think the question is, what makes reality - an individual opinion, or the mass-consensus? This is always a delicate question to ask.

fit2rule 11y ago

Everything I've ever wanted to be able to do with C++, I can do with Lua. I see it as the obvious progression from C - though I still find C a highly useful language. Putting Lua on top of whatever needs to be low-level, written in C, provides the next-generation toolset that I find so very productive.

sudeepj 11y ago

The fact that C++ is vast is well known. If a language supports some arcane things then it will end up in the code (even if its very less percentage wise). Because its arcane, most of the developers will not be able to deal with it effectively. Example of arcane: overloading comma operator.

jbandela1 11y ago

In the spirit of Greenspun's 10th Rule Any sufficiently complicated C program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of C++. For example: 1) Macros for data structures instead of templates 2) Virtual functions emulated with function pointers 3) goto fail instead of exceptions

rileymat 11y ago

My biggest problems with C++ (one of my favorite languages) 1. ABI issues. 2. Template Error messages. 3. Templates need be defined in header files (generally). 4. Object Slicing. 5. Cross platform Unicode/ASCII string encoding. I understand the reasons behind these, none the less they are really annoying.