scsh-users
[Top] [All Lists]

Lisp is neither (was Re: Ousterhout and Tcl lost the plot)

To: scsh@martigny.ai.mit.edu
Subject: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
From: ouster@tcl.eng.sun.com (John Ousterhout)
Date: 19 Apr 1997 21:20:53 GMT
Organization: Sun Microsystems, Inc.
One of the most common criticisms of my white paper has been that the
distinction between scripting and system programming is artificial, and
that it is possible for a single language to be good at both tasks.
Lisp-like languages such as Scheme were suggested as living proof.  I
can't prove that it's impossible for a single language to be good at
both scripting and system programming, but I don't know of a good example
and I doubt that it will ever happen.  The reason for this is the
difference in typing, as I explained in the white paper. A given language
embodies a particular style of typing, which can range from very strongly
typed to totally untyped.  Once that decision has been made, the language's
position on the spectrum between system programming and scripting is set.
I think it's possible to have a language that's in the middle, but it's
not likely to be terrific at either task.

Let's take Lisp as an example.  I think that Lisp falls somewhere
between scripting and system programming.  Many of you have suggested that
it is an ideal language for both system programming and scripting, but I
think that it isn't really very good for either.  In fact I suspect that
this may be why Lisp hasn't been used much for practical programming.
Lisp isn't a good system programming language because it's too hard to
write efficient programs in it and it doesn't provide good low-level
access to machine facilities.  On the other hand, Lisp isn't good for
scripting either.  In order to be a good scripting language, you need
to be able to interoperate with lots of other things, which are often
written in other languages (the best glues are those that stick to lots
of different materials).  But Lisp has never been very good at this.
For example, it's hard to include C code with Lisp because they have
very different data types and memory models.  Lisp systems are typically
closed: you have to live entirely in the Lisp world.  Good scripting
languages are open and friendly: they talk to and work with everything.

Just to short-circuit the discussion that will ensue...

I'm sure that many of you will argue against these claims ("my new
version of Scheme is just as fast as C", "Lisp just needs a new garbage
collector that embodies the latest techniques", "I know someone who
combined C with Scheme and had no problems at all", etc.).  However,
I've seen a fair amount of evidence on this and the problems far
outnumber the success stories.  Many of the best minds in Computer
Science have worked on Lisp over the last 30 years, and they haven't
been able to fix the language so that it could be widely used either
for system programming or scripting tasks.  This says to me that there
is something fundamentally wrong with the language, at least for these
tasks.

By the way, I think that Lisp is a fascinating language with neat
mathematical properties.  It's great for a variety of meta-programming
tasks where you're experimenting with new programming paradigms, such as AI
and language theory.  It just isn't good for system programming or scripting.
This reinforces my claim that you should use different tools for different
tasks.  This is also why I didn't mention Lisp in the paper.  The things I
discussed in the white paper aren't the things that Lisp was designed for
or that it does best, so it isn't really fair to compare Lisp along those
dimensions.

<Prev in Thread] Current Thread [Next in Thread>