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