Linus Flames Lisp
The following is originally posted to newsgroup comp.lang.lisp in 2007-12.
Linus Torvalds wrote:
I'm distrustful of projects that do not have well-defined goals, and well-defined interfaces. They tend to bloat and do “everything” over time. This is what gives us horrors like GNU emacs and Mach: they don't try to do one thing well, they try to do _everything_ based on some loose principle (“LISP is good” or “microkernels make sense” or “GGI should do graphics”)
I'm in general of a anti-hero attitude… and so i haven't much read any writings by Linus. However, in the past decade since i'm in the unix industry (since 1998), I have ran into a few of Linus's writings.
My impression is that he's one of the rather more pretentious type of character, prone to use words and rhetoric to smite different opinions in a nonchalant way. (but i think he's overall a good human animal)
Yesterday i was checking out what's the current status of the vapourware Fresco windows system, and in turn i was reading about GGI ([ http://en.wikipedia.org/wiki/General_Graphics_Interface ] [ https://en.wikipedia.org/wiki/General_Graphics_Interface ])
Then i ran into one of Linus's post: regarding it.
List: linux-kernel Subject: Re: GGI Project Unhappy On Linux From: torvalds () transmeta ! com (Linus Torvalds) Date: 1998-03-26 6:52:04
I don't know much about low-level programing. The article seems reasonable and level headed, but except that gratis emacs lisp vilification (and Mach). What a practical asshole.
Linus's Original Post
For historical preservation, the original article is pasted below.
List: linux-kernel Subject: Re: GGI Project Unhappy On Linux From: torvalds () transmeta ! com (Linus Torvalds) Date: 1998-03-26 6:52:04 [Download message RAW] I won't answer to any of the individual postings, but I _can_ try to explain my own personal standpoint, and at least let people know _why_ I think as I do. But before I even start on this, I'd like to point out two things that are completely unrelated to GGI, but may well explain to some people what my behaviour wrt the kernel is concerned is based on. - I have always seen my job as kernel maintainer to be acting as not only a developer, but more importantly act as a _filter_ for others. That has obviously become more and more important over time, as my personal development effort has been more and more superceded by having tens of other kernel developers. As such, my most important function is to say NO! to people. This continually surprises some people, as they see a very rapid pace of development, and often huge patches on a weekly (or even daily) basis. However, there are a few things you should realize: - I usually don't say no to driver development and stuff that doesn't impact anything else. If a new disk driver is broken, it can't be any worse than not having a driver at all, and even a broken driver is more likely to receive attention than somebody having to start from scratch. The same thing goes for architecture-specific patches that do not impact any other architecture, and doesn't impact any fundamental kernel code. I only start worrying when there are patches that imply _future_ modifications and imply a new framework for new things: THAT is when the "design" of the system starts to come into play. - There's often a backlog of patches that have been floating around for some time, and they have often had quite a bit of feedback from me before they actually make it into the standard kernel. Usually they have also had a longish period of real use by real users. - I don't see the world in black-and-white. I don't actually like Linux-only features unless they have a good reason for them, and I really like Linux to be a "standard" system (with reasonable extensions where they make sense, but they really should have either minimal impact or be _really_ sensible in somethign that there is no previous standard). The world would not be a better place if Linux were to be the only operating system out there, and we should play along with established standards if we can and when that makes sense. From the very beginning of Linux development the whole idea was not to create a Linux-centric world, but to create a good operating system that worked with what was already there. Much of early development was not modifying applications to suit Linux, but to modify Linux to suit applications. - Finally: I'm flexible. I can be convinced. But I am almost _never_ convinced by rhetoric: I'm completely unmoved by people arguing about things on a theoretical level or using pretty words and examples to get their point across. I'm _only_ convinced by real code, and by people actually _doing_ rather than talking. I may be cynical, but there's way too much hot air on the internet, to the degree that I don't believe in anything that I set sent in email or see on the internet before I've actually seen some real action. "Show me the code" can convince me, but "wouldn't it be nice if" has absolutely no power over me. Ok, with that not-so-short preface, I'll tell you a few reasons for why I have been less than entusiastic about GGI: - I think that X is good enough. Yes, X is larger than some people like, and it could be faster. But X has a lot of good features that make it better than any of the alternatives I've seen so far. I never much cared for the original SVGA-lib, and the GGI people seemed to be more impressed with SVGA-lib than with X. Yes, there are older and smaller machines that don't run X all that well, but I refuse to let those kinds of machines set the Linux design decisions. I think SVGA-lib is the correct solution for thise kinds of setups, and for anything remotely modern X is the way to go. I want to think about the _future_, not the past. Again, I can be convinced, but I need to be conviced by _actions_, not words (and "new graphics cards don't come with support in SVGA-lib" is not a very good argument, even though I've seen it multiple times. New graphics cards are usually plenty good enough for X). - I'm distrustful of projects that do not have well-defined goals, and well-defined interfaces. They tend to bloat and do "everything" over time. This is what gives us horrors like GNU emacs and Mach: they don't try to do one thing well, they try to do _everything_ based on some loose principle ("LISP is good" or "microkernels make sense" or "GGI should do graphics") For example, in fairly recent emails on the matter I have very much supported a much more _limited_ goal of trying to do everything to help the XAA ("XFree86 Accelerator Abstraction" or whatever the TLA stands for) work well. Because unlike GGI, the XAA project: - is well-defined and with very clear and defined goals - has working code already in production use (not in the kernel, but that's actually a bonus, they have a good user-level setup already, and kernel support would be only an extension of something that already works) - I've seen more arguments about GGI than about anything else. That may be because the issue is so muddled, but the point is that it's not endearing me to the project. There's a lot of [mis]information floating around, and the whole _issue_ is muddy. I don't think that leads to a good design. Anyway, I do believe that graphics support is extremely important, but I think that doing it right is more important. And I'm not going to jump head-first into anything that would be very hard to back out of before I _know_ it is right. Linus