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

Linus vs C++, again

realworldtech.com

Post reply on HN
Print view View original

71–80 of 209 posts

Re: Linus vs C++, again

#71

Post by jafl5272 »

Daniel_Newby wrote: post #51

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…

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.

Re: Linus vs C++, again

#72

Post by cageface »

martincmartin wrote: post #60
cageface wrote: post #9

As I get older and grumpier I tend to appreciate Linus' point of view more and more. It's easy to get swept up by arguments of the expressiveness of a language, particularly in small examples. However, I think in the long run it's better to have very explicit code. The less jumping around and inference I have to do to figure out what a block of code does the more likely it is that I understand it and that I can quick…

How do you explain the success of ActiveRecord? Do you think it's illusory? The exception that proves the rule? Something else? http://blog.objectmentor.com/articles/2009/07/13/ending-the-... "The fact that it took decades for the industry to arrive at something as useful as ActiveRecord in Rails is due primarily to the attitude that some language features [in this case, meta-programming] are just too powerful for ev…

Interesting question. To be honest I'm kind of on the fence with AR. It makes trivial SQL very simple but I find myself forced to drop down all the time into raw SQL for a lot of cases and I also find that AR queries with a lot of options (order, group, select, limit etc) aren't much of an improvement in readability or abstraction over the raw SQL.

What's more, I finally gave up after a year of waiting for this pretty fundamental bug in the postgres driver to be fixed and finally just hacked around it: https://rails.lighthouseapp.com/projects/8994/tickets/2622-p...

Re: Linus vs C++, again

#73

Post by rictic »

martincmartin wrote: post #60
cageface wrote: post #9

As I get older and grumpier I tend to appreciate Linus' point of view more and more. It's easy to get swept up by arguments of the expressiveness of a language, particularly in small examples. However, I think in the long run it's better to have very explicit code. The less jumping around and inference I have to do to figure out what a block of code does the more likely it is that I understand it and that I can quick…

How do you explain the success of ActiveRecord? Do you think it's illusory? The exception that proves the rule? Something else? http://blog.objectmentor.com/articles/2009/07/13/ending-the-... "The fact that it took decades for the industry to arrive at something as useful as ActiveRecord in Rails is due primarily to the attitude that some language features [in this case, meta-programming] are just too powerful for ev…

ActiveRecord, like much of Rails, is all about context. ActiveRecord is designed to create a domain specific language for interacting with a relational database. By Linus' reasoning, if you had a project where interacting with a relational database was a significant and pervasive part of the app, then may be worth the tradeoff of bringing in the context and assumptions of a system like ActiveRecord.

In a huge, sprawling project in which the relational database is a small portion, it may not be worth trading the power of ActiveRecord for the accompanying loss of explicitness and clarity.

Re: Linus vs C++, again

#74

Post by jafl5272 »

rpledge wrote: post #4

Linus has a touch of what I think makes Steve Jobs great: the ability to say no and stick by those convictions. No argument from me that Linux is wildly successful and one of the most important tech developments in the last 10 years. However, I always cringe when I read some of his comments that seem to reject any element of forward progress. While C++ certainly has its share of issues, Linux will never evolve if the…

He's not rejecting progress. He explicitly says that C isn't for everything. But he wants real progress: a language with GC, concurrency, etc., not just C-with-classes-plus-etc-etc-etc

Re: Linus vs C++, again

#75

Post by forgottenpaswrd »

mojuba wrote: post #31
cageface wrote: post #9

As I get older and grumpier I tend to appreciate Linus' point of view more and more. It's easy to get swept up by arguments of the expressiveness of a language, particularly in small examples. However, I think in the long run it's better to have very explicit code. The less jumping around and inference I have to do to figure out what a block of code does the more likely it is that I understand it and that I can quick…

write(fd, buf, size); Can you list all the caveats, possible side effects, reasons of failure of this simple C function call? Hint: remember, fd can be a file, as well as a NFS-mounted file, pipe, network or local socket, FIFO, device, etc. Hint2: I doubt anyone can give a comprehensive description of the possible consequences of this call. Bottom line being, C can be incredibly hard to understand, or C++ can be clea…

Hard to understand?

Really? write a block of data of size on bytes "bytes" on the file-pipe-network... pointed by the file descriptor "fd"??

It is extremely simple to understand, it makes a very simple thing, always right. I doubt you can make it simpler.

I have been using this all my life for NFS-mounted file, pipe, network or local socket... Never had any problems, and I have done very complex things.

Of course, in c++ you will use the very same function under a different calling, you can make it part of a class, whatever, but is going to use the same backend internally(because the OS only uses one), only that you can add a lot of abstraction(complexity) from c++ code.

Of course C++ could be clean, but the question is: what will happen if we make it into the kernel?. Linux thinks it won't work. I agree with him.

Re: Linus vs C++, again

#76

Post by dkarl »

Daniel_Newby wrote: post #51

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…

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.

Re: Linus vs C++, again

#77

Post by forgottenpaswrd »

rpledge wrote: post #4

Linus has a touch of what I think makes Steve Jobs great: the ability to say no and stick by those convictions. No argument from me that Linux is wildly successful and one of the most important tech developments in the last 10 years. However, I always cringe when I read some of his comments that seem to reject any element of forward progress. While C++ certainly has its share of issues, Linux will never evolve if the…

It is actually good as it is, like scientific progress, if someone wants to make a new kernel in .NET or Lisp, he could fork it and prove is better that way. But please don't force everybody to follow you.

MS created Vista using 2000s paradigm. It was slow as a snail.

Experiments could fail too.

Re: Linus vs C++, again

#78

Post by alnayyir »

chromatic wrote: post #64
stcredzero wrote: post #40

Earlier quoted context omitted.

I started designing a language where you had lexically scoped "contexts" to specify the meanings of words. In general a package/library would be a context, and could declare its dependency on other contexts. Any words with conflicting interpretations would have to use its full global specifier to compile.

Perl does this, Perl 6 especially.

Sadly x86/arm/mips/sparc/power processors aren't Perl machines and Perl6 thusly can't be used to make a kernel for a Unix derivative.

Re: Linus vs C++, again

#79

Post by CUViper »

mojuba wrote: post #31
cageface wrote: post #9

As I get older and grumpier I tend to appreciate Linus' point of view more and more. It's easy to get swept up by arguments of the expressiveness of a language, particularly in small examples. However, I think in the long run it's better to have very explicit code. The less jumping around and inference I have to do to figure out what a block of code does the more likely it is that I understand it and that I can quick…

write(fd, buf, size); Can you list all the caveats, possible side effects, reasons of failure of this simple C function call? Hint: remember, fd can be a file, as well as a NFS-mounted file, pipe, network or local socket, FIFO, device, etc. Hint2: I doubt anyone can give a comprehensive description of the possible consequences of this call. Bottom line being, C can be incredibly hard to understand, or C++ can be clea…

That same write call can exist in C++ too, with exactly the same consequences. Everything ugly in C can be done in C++, but C++ lets you be so much uglier.

  int i = 42;
  foo->bar(i);
In C, we can tell that foo is either a "struct S* foo" or "union U* foo" which has a member "X (*bar)(Y)". Type X is unknown from this context, but Y is some type compatible with int. We will call the function which bar points to with a single value 42. The value of i will be unchanged.

In C++, it could be the same. Or foo could be not a pointer at all, but some object with "operator->". bar() might take its first parameter by reference and end up changing i. bar() might have additional parameters with default values. bar might not even be a function, but some object with "operator()". etc. etc.

Most of the code I write is C++, so I'm not against it -- but I definitely understand the point that C requires less context.

Re: Linus vs C++, again

#80

Post by jongraehl »

Because the Linux kernel is so important, and so difficult to replace, people will put up with whatever language inconveniences they must in order to get their contribution accepted.

Therefore, I don't see Linus' choice as having any larger significance.

I already know that C++ is a vastly superior language to C for small to medium scale programs where computational time+space efficiency is paramount.

Post reply on HN