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

91–100 of 209 posts

Re: Linus vs C++, again

#91

Post by [deleted] »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

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

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

[deleted]

Re: Linus vs C++, again

#92

Post by [deleted] »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

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

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

[deleted]

Re: Linus vs C++, again

#93

Post by eru »

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…

> However, I think in the long run it's better to have very explicit code.

You should love (parts of) Haskell then. You even need to specify whether your code can have any side-effects there.

(Haskell's Type-classes are awfully implicit, on the other hand. Though not nearly as bad as overloading in C++. You do not need to abuse bit-shifting for sending stuff to streams in Haskell. If you want/need to, you can just make up your own new line-noise operator. That new operator won't be used anywhere else, and is thus perfectly grep-able.)

Re: Linus vs C++, again

#94

Post by cageface »

swannodette wrote: post #67
cageface wrote: post #55

Earlier quoted context omitted.

If the expressive code was written with a good level of abstraction, it should be pretty straightforward to figure out what it does. Abstractions are necessary, of course, but they also leak. Good judgment in these issues is one of the hallmarks of an experienced programmer. I'm just finding in my own code that I'm gravitating towards less abstraction, not more. Clojure in it's current incarnation is a great example…

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

Re: Linus vs C++, again

#95

Post by eru »

bretthoerner wrote: post #88
ramidarigaz wrote: post #81

Earlier quoted context omitted.

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

It's the man page section number. I believe this dates back to when the man(uals) were actually printed out. You'd go to section 2 to find X to disambiguate from a different Y. http://www.december.com/unix/ref/mansec.html

And the disambiguation is still useful.

Re: Linus vs C++, again

#96

Post by steveklabnik »

hristov wrote: post #43
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 beca…

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

Lots of people write lots of kernels in lots of languages. I have some (small) contributions to one in D, for example. While still explicitly a systems language, there's still lots of room for people to write kernels in whatever they want.

Re: Linus vs C++, again

#97

Post by steveklabnik »

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…

As someone contributing to a new OS, these are hard problems, for sure. At the same time, I personally see a pretty big future where the web enables lots of new systems work.

See, even though Joe Blow may use Windows, he still uses Linux when he Googles. The web allows people to not have to worry about what OS the servers are running... so I think there's lots of room for innovation on the OS front, but on the server side of the cloud.

Re: Linus vs C++, again

#98

Post by tptacek »

ramidarigaz wrote: post #81
tptacek wrote: post #42

Earlier quoted context omitted.

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

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

You got a lot of good answers here, but just so you know: you really only have to remember that open(2) is a syscall and fopen(3) is a library call. That's the important distinction.

Re: Linus vs C++, again

#99

Post by tptacek »

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…

He's just pointing out that the first argument to write() is the exact same kind of abstraction as the "foo" in "foo->perform()".

Re: Linus vs C++, again

#100

Post by steveklabnik »

mkramlich wrote: post #59
huherto wrote: post #44

Earlier quoted context omitted.

I would like to hear Linus opinion on Go.

Or D. I had thought D was designed to be, among other things, a reasonable next-generation replacement for projects that would otherwise use something like C.

Yep. I'm actually contributing a bit to an exokernel written in it.
Post reply on HN