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

41–50 of 209 posts

Re: Linus vs C++, again

#41

Post by dman »

tptacek wrote: post #24
mcav wrote: post #20

Earlier quoted context omitted.

The clojure analogy actually works in favor of them switching to C++. Clojure takes the good ideas of Lisp and bolts extra convenience (and modernization) on top, just like C++ adds extra convenience to straight C.

C++ is not just C with extra stuff. C++ programming and C progamming are different enterprises. The Linux kernel is full of all sorts of explicit "this block of memory is a struct txaz_fooblock and here's how we link them together" that C++ programmers simply don't write. This is before you even get into things like the template-y standard C++ library.

C++ played the C as a gateway card very heavily early on, in the 80s that was a brilliant strategy, now not so much. If youre interested in efficiency straight C does fairly well (also because building foreign function interfaces for C code is much easier), if youre interested in correctness then some variant of haskell or ml will serve you with actual type checking, and if speed of writing code is what youre after then some dynamic language will do.

Re: Linus vs C++, again

#42

Post by tptacek »

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's userland code. In the kernel, write(2) very quickly finds the open file based on the fd and passes the call off to extremely explicit code that handles the write().

Stripping off ambiguity is almost the write syscall handler's only job.

It's worth mentioning here that not only is the convenience vs. explicitness tradeoff different in application code than in bare-metal systems programming code, but that that specific example of convenient app-level API is also an infamous Unix failure. In reality, app code cannot safely assume that an fd is just an abstract bucket you can read, write, close, and seek in.

Re: Linus vs C++, again

#43

Post by hristov »

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 very silly to say that something is bad because it started a long time ago. I do not see how any of the modern languages of the 21th century would be even remotely suitable to write an OS kernel with. Considering that most of those languages are at least partially interpreted and require GCs, a kernel written in them would be painfully slow.

Just because something is old does not mean it is worse, and just because something is new it does not mean it is better.

If you think about it, the modern languages are clearly made for programming higher on the stack (i.e., at application level). That makes a lot of sense. After all most programming is done at the application level, and it would make sense to write a language that makes that type of programming easier. And of course many modern languages are very successful in that respect. But it is silly to assume that just because they are successful at the application level they would make good kernel programming languages.

The reason why C++ is the language being considered is that it is also a relatively low level language which means that it can potentially replace C for kernel level programming. That of course does not mean that it should, and Linus does a good job of pointing out the issues with C++.

Re: Linus vs C++, again

#44

Post by huherto »

sliverstorm wrote: post #23

This leaves me with a burning curiosity. Linus, if you could change the Linux kernel to another language, would you? In a perfect world (i.e. migration concerns and such aside), if you were changing the Linux kernel to another language, what language would you choose? If you feel C is still the #1 choice, what would the #2 choice be?

I would like to hear Linus opinion on Go.

Re: Linus vs C++, again

#45

Post by [deleted] »

koenigdavidmj wrote: post #32
j_baker wrote: post #13

Earlier quoted context omitted.

I'm not really sure you understand what a context-free language[1] is. I suppose global variables can be seen as being context-sensitive, but functions with weird names definitely don't qualify a language as context-sensitive. [1] http://en.wikipedia.org/wiki/Context-free_grammar

No, what he means is that something like foo * bar; Can mean two different things. If foo is a defined type (typedef int foo, for example) then that declares a variable bar of type foo. If it is not, then we're multiplying variables foo and bar.

[deleted]

Re: Linus vs C++, again

#46

Post by dman »

viraptor wrote: post #35
dman wrote: post #21

Earlier quoted context omitted.

From linus's post - "And the best way to avoid communication is to have some "culture" - which is just another way to say "collection of rules that don't even need to be written down/spoken, since people are aware of it". Sure, we obviously have a lot of documentation about how things are supposed to be done, but exactly as with any regular human culture, documentationis kind of secondary." He seems to suggest that s…

I don't think anyone can surprise us with something big now. It was easy to come up with a new, revolutionary OS in 80s/90s - you could write one yourself. Right now, anyone writing an OS for the OS itself (not for research) has failed before they start (unless they've got a large experienced team and loads of money to burn). You have hardware you cannot easily access, loads of applications you cannot make a compatib…

Fully agreed, though i would love to be proven wrong by someone coming out of the blue and creating something from scratch.

Re: Linus vs C++, again

#48

Post by johnrob »

I think Linus is making the right call here. At a 10,000 foot view, the real argument is about style. The style of C happens to be one that lends itself to easier groking of code amongst hundreds of developers (as he illustrated well). Sure, C++ may be a more modern tool with some more powerful features, but using it may not be the best thing organizationally.

This kind of thinking is refreshing and is seemingly rare in classrooms. There, you mostly learn 'what to use' and not 'how to determine what you need'. Just as I'd expect, over design is the most consistent issue I come across in co-workers' code. 'Write code to be read' is a metric that seems to have gone out of style. Code that does X-Z-Y should, in my opinion, look like code that does X-Y-Z. Otherwise the reader has to invest time and energy figuring out the design. There had better be a good reason to justify a hard-to-grok design, because it will continue to be a drain for the life of the project.

Re: Linus vs C++, again

#49

Post by tptacek »

fleitz wrote: post #36
tptacek wrote: post #24

Earlier quoted context omitted.

C++ is not just C with extra stuff. C++ programming and C progamming are different enterprises. The Linux kernel is full of all sorts of explicit "this block of memory is a struct txaz_fooblock and here's how we link them together" that C++ programmers simply don't write. This is before you even get into things like the template-y standard C++ library.

Agreed. C++ is more like Bjarne Stroustrup bolts everything he's ever heard of onto C than "C with classes". Blatantly plagarized from: http://www.cvaieee.org/html/humor/programming_history.html

I'm not making value judgements (yet). I'm just saying that, for instance, programming with templates, or modeling events as objects that are stored and passed around, or just basic nuts-and-bolts stuff like what your go-to code is for an array of elements; these are very different in C++ than they are in C. The idioms are different, the libraries are different, the principles are different.

Re: Linus vs C++, again

#50

Post by protomyth »

I know no tool would solve every problem, but I can't help but wondering if someone developed and IDE that truly got C++ would that allow C++ to be used by more projects. Seeing grep referenced for code searches reminds me that grep has no knowledge of the context of anything in a searched file. It almost seems like C is the only choice if you can't go beyond context-less tools.

//a grep specifically for C++ code - hum

Post reply on HN