Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds on C++ (2007)

thread.gmane.org

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Linus Torvalds on C++ (2007)

#11

Post by gizi »

Elv13 wrote: post #6

> 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…

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.

Re: Linus Torvalds on C++ (2007)

#12

Post by devnonymous »

uv3d779b wrote: post #7
NeutronBoy wrote: post #4

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

Typical Linus. Pretty much an opinionated ass, with very (very very) few of the positive connotations that come with being opinionated.

Typical Troll. Pretty much a flame-bait comment, with very (very very) few of the objective truths should that come with being a commenter.

Re: Linus Torvalds on C++ (2007)

#14

Post by Elv13 »

gizi wrote: post #11
Elv13 wrote: post #6

> 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…

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.

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

Re: Linus Torvalds on C++ (2007)

#15

Post by StephanTLavavej »

Elv13 wrote: post #14
gizi wrote: post #11

Earlier quoted context omitted.

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.

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…

In C++11, auto just says, "make the type of this thing the same(ish) as the type of its initializer". There is no potential for code bloat, even in theory. In C++14, auto can be used for generic lambdas, but even those are almost always called with a single set of argument types, so again no code bloat even in theory.

(Template code bloat itself is nearly mythical. I've seen exactly one occurrence of it causing a problem, in 8 years of Standard Library maintenance.)

Re: Linus Torvalds on C++ (2007)

#16

Post by StephanTLavavej »

gizi wrote: post #9

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++.…

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.

Re: Linus Torvalds on C++ (2007)

#17

Post by tbirdz »

StephanTLavavej wrote: post #15
Elv13 wrote: post #14

Earlier quoted context omitted.

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…

In C++11, auto just says, "make the type of this thing the same(ish) as the type of its initializer". There is no potential for code bloat, even in theory. In C++14, auto can be used for generic lambdas, but even those are almost always called with a single set of argument types, so again no code bloat even in theory. (Template code bloat itself is nearly mythical. I've seen exactly one occurrence of it causing a pro…

In my experience code bloat from templates comes mostly from libraries whose authors are much less skilled than those of the standard library.

Re: Linus Torvalds on C++ (2007)

#18

Post by M8 »

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

Re: Linus Torvalds on C++ (2007)

#20

Post by [deleted] »

M8 wrote: post #18

"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]
Post reply on HN