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

131–140 of 209 posts

Re: Linus vs C++, again

#131

Post by RyanMcGreal »

dman wrote: post #46
viraptor wrote: post #35

Earlier quoted context omitted.

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.

If anyone does manage that, it will be someone who was never told it was impossible to do.

Re: Linus vs C++, again

#132

Post by russell_h »

forgottenpaswrd wrote: post #75
mojuba wrote: post #31

Earlier quoted context omitted.

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…

I have to disagree with you with regards to write(). The write(2) man page is deceptively simple, check out open(2), specifically the NOTES section. I count 12 occurrences of the string "NFS".

My favorite part of the whole man page is the Linus quote:

    "The  thing  that  has always disturbed me about O_DIRECT is that the whole interface is
    just stupid, and was probably designed by a deranged monkey on  some  serious  mind-con-
    trolling substances." -- Linus
But thats not a language failing. A language that actually prevents you from writing complicated interfaces is probably entirely unsuitable for... almost anything.

Re: Linus vs C++, again

#133

Post by perlpimp »

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…

When we were taught an OO course, we had smalltalk first, and then we moved to C++. Professor enumerating all rules, ifs and buts was like an operator of a german machine gun that was mowing down wave after wave of good natured allied programmers. Or so it felt and classmates have conferred on my feelings.

C++ has too many rules and exceptions, while giving some sort of control to a genius - in hands of a good natured well meaning coder, it all goes to hell. That is so not in the beginning but in the long run.

All misgivings noted, compilers gone to future and back. They help alot.

C has few rules, and whats more if you use UNIX / ISO convention there are very few ways you can go wrong. C++ is an ugly duckling of era of 586 type machines, when you have tried to do something in binary , efficiently and with a style and yet still was found wanting.

Explicit is always best, because you always refactor. Say what you mean, write what it does. This way its easier to read, and easier to coax it to do something else. In the end good coders achieve things by correcting few things here and there. If you have some sort magic that developer can't trust to be exactly what they expect it to be - they can't code with honestly and without fear. And fear as we know is a mind killer. So it is a catch 22.

I am totally 100% with Linus on that one.

Re: Linus vs C++, again

#135

Post by swannodette »

cageface wrote: post #94
swannodette wrote: post #67

Earlier quoted context omitted.

Gotta disagree. Good stack traces are about the maturity of the compiler and tool support- they have absolutely nothing to do with clarity of the language. Clojure is simple and Clojure opts for explicit context over implicit context almost everywhere (dynamic binding being a big exception)- this is exactly what Linus argues for. All you have in Clojure are functions and values - how much straightforward can you get?…

You're looking at Clojure from the point of view the language specified by the docs though, and I'd agree as far as that goes. From another point of view, Clojure, like all higher level languages, is just an abstraction over an underlying machine. From this angle and in it's current state it's (IMO) a pretty leaky abstraction. I think it's fair to say that this has more to do with the implementation than the design t…

C is just an abstraction over the underlying machine. The amount of tooling to required to make C programming bearable is staggering - how much leakier can you be?

Re: Linus vs C++, again

#136

Post by jshen »

cageface wrote: post #72
martincmartin wrote: post #60

Earlier quoted context omitted.

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

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

This was how I felt when I first scratched the surface, but by using find(...) instead of raw sql you leave open other options for the future like using :include

Re: Linus vs C++, again

#137

Post by xpaulbettsx »

Let's put it this way without any subjectivity: every production kernel that you folks use every day is written in C. NT is, Solaris is, Darwin is, and Linux is.

Not one production-level kernel that is in wide use as a general-purpose operating system uses C++. I don't believe that to be a coincidence.

(Nitpicker's corner: Darwin's device tree subsystem is written in Embedded C++, an extremely cut-down version of C++ that's more like "C with classes" than C++).

Re: Linus vs C++, again

#138

Post by sophacles »

joe_the_user wrote: post #117
martincmartin wrote: post #60

Earlier quoted context omitted.

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…

If the kernel was written to the common standards of Ruby code, it would come apart completely. -- > That doesn't mean Ruby is bad. Ruby is great. ActiveRecord is a great model for MVC web development. The standards of Ruby aren't good for more performance-oriented, "hard core" development - Ruby's a pretty mature language but Rubinius, the Ruby-in-Ruby project still isn't production-level. One might guess that compi…

There really wasn't much in terms of "good and bad" overall, just "good and bad" for Linux. At the end he says (paraphrased)"I'm not saying this is for every project, but if you are going for more than C, skip C++ and go for ".

Re: Linus vs C++, again

#139

Post by sophacles »

nitrogen wrote: post #114
rpledge wrote: post #34

Earlier quoted context omitted.

Great way to edit my comment, what I actually said was: > Linux will never evolve if the programming paradigm stays in the 60s C is a great language, but I firmly believe that OOP creates more maintainable code that is more robust. Sure, a simple C program is easy to understand, but the kernel isn't an easy program. Don't get me wrong, C++ has major downsides, but C isn't a magic bullet.

The kernel does use object-oriented paradigms.

The kernel is also shockingly simple. Sure there are some tricky bits, but writing kernel code is very straight-forward. In fact every time I've written kernel code it has always been a "it can't really be this simple" type moment -- but some of that code is still running production machines today so... it must have been.

NOTE: this is not me bragging, it's me suggesting the mystique is a bit undeserved.

Re: Linus vs C++, again

#140

Post by _0ffh »

jongraehl wrote: post #80

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.

Come again, please? All computational time+space efficiency of C++ comes from the "C", not the "++" part!
Post reply on HN