Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!sdd.hp.com!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: The future of Lisp
Message-ID: <3993@skye.ed.ac.uk>
Date: 23 Jan 91 14:32:17 GMT
References: <1991Jan21.225418.22130@cs.cmu.edu>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 67

In article <1991Jan21.225418.22130@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes:

   -- More people than ever before believe that "industrial strength"
      Lisp systems are too big and complex.

   -- "Industrial strength" Lisp systems are too small and simple.

While I agree with most of what RM wrote, one thing that seems to
be missing is an explanation of why more people than ever are wrong.
Why do so many think the systems are too big and complex when they
are actually too small and simple?

I think that the following are among the reasons:

  1. It often seems that equally powerful systems might have been
     achieved while remaining less complex if better means of
     controlling complexity had been used.

  2. In too many implementations of CL, it is too hard to escape
     their large size when you no longer need it.  (Though it looks
     like this is being fixed...)

There is also a tendency to blame the language for the sins of
the implementations.  I think it would be unfortunate if Common
Lisp _had_ to be large and complex so that one had to turn to
other dialects in order to deliver smallish applications.

RM also wrote:

   What we are seeing here is the *history* of Lisp.  MULTICS EMACS
   was written in an industrial strength Lisp because the developers
   understood that Lisp features would make it easy to implement a
   revolutionary text editor.

As you know, Multics Emacs was written in Multics MacLisp.  In those
days it was InterLisp that went all out to provide power tools in one
large system.  MacLisp was much simpler, and many of the tools were
somewhere else, such as in the editor.

While MacLisp may have been industrial strength for its time, it is a
much smaller Lisp than Common Lisp.  Many people who were happy with
Lisps of that size, and who would have welcomed new features that
could be added in a modular way, were dismayed by Common Lisp, because
it seemed to greatly increase the size of the basic language.

Moreover, Multics Emacs was an important development because it showed
that Lisp could be used for text editing, an application that had
seemed to belong to other languages.  It began to seem that Lisp might
be able to move into the mainstream, something that has not happened
as much as we once hoped.

Some people are inclined to blame Common Lisp for such failures.
For the most part, I disagree.  I think it is more accurate to say
that implementations have tended to address certain concerns more
than others.  But what I hope will happen is that implementations
will change, or new implementations be developed, that address
a greater (or different) range.

[BTW, I'm pleased by what I've seen of CMU CL (formerly Spice Lisp).
Indeed, I first learned CL by using Spice Lisp on a Perq back in
1984 or so.]

-- jd

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton