firstname.lastname@example.org (John Ousterhout) writes:
> 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.
You don't tell us though what typing has got to do with "systems vs
scripting". You don't say why a dynamically typed language can't be a
good systems language (lisp), or a statically typed language can't be
good at scripting (ML perhaps?)
> 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
I don't find it hard to write efficient programs in it. On what basis
do you make this comment?
> in it and it doesn't provide good low-level
> access to machine facilities.
This is news to me. Give us an example.
> 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.
This is a very strange comment indeed. Tcl and C have *very* different
data types and memory models. But you would have us to believe they
complement each other perfectly. Now you say that Lisp isn't good at
this because it has different types and memory model to C?? Actually
Lisp is much closer to C than Tcl is to C. So what?
> Lisp systems are typically
> closed: you have to live entirely in the Lisp world.
This is news to me. All lisp systems that I've used allow you to link
in C libraries.
> 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
Is this the extent of your research into this subject? A few anecdotes
and a few usage statistics?
When I think of a good systems programming language I think of a
language that would be good for writing the UNIX systems utilities
in. Having written a few of these myself (like "ls") in C, I can say
with certainty that something like lisp or scheme would be much nicer
than C, and probably just as efficient. It would probably avoid some
of the built in limitations that tend to crop up in UNIX utilities
(like line length and error handling), because it's just too much
effort to do it "right" in C.
> 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
Isn't fair for who :-)