6 ms·

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 succes

• desponsible 16y ago
  > Linux will never evolve Do you terribly mind elaborating on this rather bold statement?
  • deleted 16y ago
    [deleted]
  • silentbicycle 16y ago
    Rob Pike already has: http://herpolhode.com/rob/utah2000.pdf http://herpolhode.com/rob/utah2000.pdf
  • rpledge 16y ago
    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.
    • nitrogen 16y ago
      The kernel does use object-oriented paradigms.
      • sophacles 16y ago
        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.
        • nitrogen 16y ago
          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).
        • beagle3 16y ago
          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.
      • deleted 16y ago
        [deleted]
• fleitz 16y ago
  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.
  • mcav 16y ago
    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.
    • tptacek 16y ago
      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.
      • mcav 16y ago
        True. I hadn't considered that.
      • fleitz 16y ago
        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 http://www.cvaieee.org/html/humor/programming_history.html
        • tptacek 16y ago
          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.
• yonilevy 16y ago
  Well, he did create git. Not that your point isn't valid, just pointing out Linus is actively helping forward progress.
  • rpledge 16y ago
    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.
  • tbrownaw 16y ago
    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 :)
    • shadytrees 16y ago
      > (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.
      • tbrownaw 16y ago
        I work on monotone ( http://monotone.ca/ 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/ 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.
    • chousuke 16y ago
      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?
• jrockway 16y ago
  If C is 1960, C++ is 1961. It'd be nice to join the 21st century, or even 1980.
  • eru 16y ago
    C++ is from the early 1980ies. (That doesn't make it a better language, though.)
    • jrockway 16y ago
      Metaphor.
      • eru 16y ago
        I prefer my metaphors sharp and cutting.
• dman 16y ago
  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.
  • viraptor 16y ago
    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.
• deleted 16y ago
  [deleted]
• hristov 16y ago
  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++.
  • ComputerGuru 16y 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. 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.
    • Daishiman 16y ago
      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.
  • steveklabnik 16y 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. 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.
• jafl5272 16y ago
  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
• forgottenpaswrd 16y ago
  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.
• wvenable 16y ago
  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.