Hacker News Reader

Comment by rpledge | Hacker News Reader

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 programming paradigm stays in the 60s. My gut feel is there is a lot of opportunity to do better over the next ten years.

View on HN

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

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

Not true. You just have to be smart enough to implement the stack and structure properly. Have a look at some of the experimental operating systems out there. Singularity is especially worth a look.

Yes, and still hasn't solved its performance problems that span all of the OS's functionality. Performance is something we might not care about at a high level, but on a kernel it's a first priority, and a very difficult problem to solve.

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

The counter arguement would be that it is silly to reject sonething because it is new. I've written. Lots of C++ to test SOCs at a lower level than the linux kernel. Discounting OOP techniques because of complexities in C++ is shortsighted.

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 sticking C keeps the focus on attracting people who like to build things. There are surely very productive programmers who use c++ and other newer languages but sometimes embracing new developments means opening the door to people who are just following fads. Just as an example - the kernel has managed to avoid the following developments - uml, xml etc. Not saying that uml and xml dont have their legitimate uses, but sometimes keeping things bare and simple has the effect of keeping posers out. As a sidenote, I dont seem to recollect any recent groundbreaking progress in languages for systems level programming (singularity from microsoft might be an exception). At some point people were trying things like oberon, lisp machines, but I dont seem to recall any new developments which explore dynamically different ways of building computer systems. For better or for worse we seem to have settled on a local optima of c and unix based systems.

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 compatibility layer for, etc. etc.

When you created a lisp machine, it was a lisp machine - everyone knew why and how you did it (to some extent). If you wanted to run it, you ported "the program" to it and all was good. Right now you have users expecting at least the stuff they can get from other popular systems - and that's years of work away for any new project.

The best you can probably do, as far as "progress" goes is to create a new research system and port the good stuff back to mainstream (singularity, plan9, etc.)

To some extent we know all there is to know right now... New languages, periferials, usage ideas are still created. But for a new system language you need to either create or port a system and gather some followers. That's a big step.

Edit: Actually I believe that there's a new hardware change coming that will make current computers ineffective in some way. We could switch to new hardware, new languages, new systems... we could start from scratch :) I don't believe the current ways of parallelising computation can do that.. but if someone constructs a concurrent bus/memory/cpu that could invalidate some of the normal programming ideas.

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.

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.

I'd like to see Linus tackle a systems programming language now that he's tackled version control. I'd think that would be entirely within his domain.

But C++ is not the answer here. It wants to be all things to everyone (low-level, high-level, object-oriented, functional, etc, etc) and is therefore useful for almost every kind of project but well matched to none of them.

Linux is FOSS, so if there are huge benefits to using C++ then the people who advocate such things should simply take the tree, fork it and start doing some C++ stuff. If their arguments are correct it should soon be fantastic and much better than Linux.

Also, there is nothing wrong with programming paradigms from the 60s as evidenced by the popularity of Clojure and other functional languages that borrow heavily from LISP.

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.

True. I hadn't considered that.

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.

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.

No. It isn't about avoiding "modern" conveniences, it's about avoiding the specific baggage (a highly contextually-dependent grammar and operator overloading are two examples given) that C++ drags with it.

He ends with: "But C++? I really don't think the "good features" of it are very good at all. If you leave C behind, do it properly and get some real features that matter. GC, some concurrency support, dynamic code generation, whatever."

Clojure actually removes a lot of things from lisp. So it might not be a very good analogy to c and c++. For eg clojure doesnt have an object oriented framework like CLOS, does not have reader macros, currently has a much smaller set of inbuilt functions. Not to say it hasnt added new stuff, it has, eg persistent data structures, deep integration with the jvm. Also importantly all valid lisp programs are not valid clojure programs. In short, its a clean break from lisp which carries the useful ideas and the spirit of lisp forward.

Well, he did create git. Not that your point isn't valid, just pointing out Linus is actively helping forward progress.

Excellent point, git is certainly innovative. It's a great example of someone smart seeing a problem with his workflow and fixing it (although this isn't 100% what happened, the whole bitkeeper/closed source debacle played a hand). I guess my point is that I haven't seen too much development in the core kernel lately, especially wrt helping use multicore better.

Not sure I'd call intertwingling the repository/workspace like that, or conflating branches and repositories, "progress". But I suppose it's better than svn/cvs/etc that it's largely taking its users from.

(disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)

> (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)

Wait, you can't just write that and end your comment! What VCS do you work on?, if you're at liberty to share.

I work on monotone ( http://monotone.ca/ ) which is older and I think conceptually cleaner, and that was a reference to this earlier rant (last paragraph): http://lwn.net/Articles/249460/ . We've also gotten a few comments about the code being very nice, so I doubt it's really all that messy and unmaintainable.

The repository/workspace issue I can agree with (though there is an environment variable that you can use to specify a repository outside the current directory), but what do you mean with "conflating branches and repositories"?

In git, branches are not a special entity. They are a property of the contents of the repository. The commits form a DAG, which is also a tree, and trees often have branches. A repository might have dozens of branch points that are never referenced by name, but that doesn't mean they don't exist.

You can even consider the whole set of repositories for a single project as forming a logical DAG in this manner. However, because of the distributed nature of git, there will be branches that are not visible to you.

Given this, what does it mean to somehow "separate" the concept of repositories from branches?

Perhaps a better way of saying that would be that they picked a very unique (re-)definition of what a branch is (something like "pair<repository * , commit * repository::*>").

I tend to think of a branch more as "a buch of commits that go together", which seems to fit very nicely with common usage where you have a release branch, dev branch, etc. It just seems very bizzare that people working on the "dev branch" are actually working on entirely separate branches just because they're in different offices which use separate local mirrors in case the internet breaks.

If git has defined 'branch' to mean something different from other VCS, then I think git got it right and everyone else is wrong.

The distributed nature of git (and any DVCS) means developers on the 'dev branch' are working on different branches, even if they all call it 'dev' in their local repositories. Their local development may have started from the same parent, but it's not the same branch. If you send the commits to someone else, they'll be completely separate from the receiver's dev branch until merged.

It seems to me that your idea of the "dev branch" is in git a purely non-technical thing. That is, a branch in some blessed repository that points to the so-far merged efforts of all the developers' dev branches, representing 'current' development.

I think this is a good thing, and I'm yet to be convinced otherwise.

If C is 1960, C++ is 1961. It'd be nice to join the 21st century, or even 1980.

C++ is from the early 1980ies. (That doesn't make it a better language, though.)

Metaphor.

I prefer my metaphors sharp and cutting.

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

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.

> Linux will never evolve

Do you terribly mind elaborating on this rather bold statement?

Rob Pike already has: http://herpolhode.com/rob/utah2000.pdf

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.

I definitely agree. It is the simplicity of the POSIX userspace APIs and the Linux kernel internals that make me enjoy Linux so much.

I still think there is some art to writing simple, efficient code, though. Most system-level code looks quite simple when it's done, but it may have taken several iterations to get it fast, clean, and small enough (particularly on embedded devices -- I once had to find 200 spare bytes to fit a bug fix in a 256KB firmware by hand optimizing various ancient parts of the code base).

Well, the kernel is so shockingly simple in part BECAUSE no one let C++ in. And it is a testament to Linus' great leadership and censorship that it remains that way.

Reply on news.ycombinator.com