Re: Improving the LISP working environment by taking a lesson from...

[SHRAGE at WHARTON (Jeffrey Shrager)]

APL!

I think that there are several problems inherent in the design of LISP and
its environment that have been neatly avoided in APL.  I think particularly
of the following:

  1- When a programmer writes a function for his system it is "eaten" by
     LISP.  That is, it becomes a part of the workspace as if it had been
     there all along.  This is "neat" but painful for large system design
     because it means that you need to carry around a notebook of all your
     functions in order to remember what you have there.  In APL, you can ask
     the system to list the names of all your functions or variables.  This
     is a simple, but powerful idea and should exist in LISP without having
     to go trapsing thru the oblist.   Also, the ability to get these
     names into a data structure (admittedly somewhat klugely implemented
     in APL) permits the writing of workspace documentor programs and the
     like.
  2- The CONTINUE workspace feature of APL permits a user to logout and
     come back an hour later, the next day, etc with his environment
     intact as he left it (this also happens if, for some reason, the
     system craps out).  This is simple enough; a common checkpoint name
     that is automatically restored when LISP starts up if it exists.
  3- LISP has this one real unfortunate feature; it is too flexible and
     too simple simultaneously.  This is the reason that it is soo hard
     to transport LISP systems from one machine to the next.  "Basic LISP"
     is so trivial that noone can write anything in it.  Thus, every impl-
     ementation has devised their own set of cover functions thus making
     programs written there completely incompatible with the rest of the
     universe.  The flexibility of LISP makes this a real easy task.  APL
     is not quite as flexible (you cannot easily add "primatives" to the
     main loaded system but the primative set is sufficiently rich that
     you usually do not need to do so.  Thus APL is, probably, one of the
     most transportable languages in the world [don't thumb your nose
     at transporatbility -- it is quite important if you ever expect to
     see any of your work outside of MIT].  The MAPCAR, etc functions
     were a half-hearted attempt to correct the problem of the simplicity of 
     LISP -- useful and more powerful than CAR CDR...  I don't know quite
     what to do about this one -- since the NIL people are writing a "new
     LISP" they might be able to make use of this commentary I think that
     the MacLISP users are already fried (sorry).

Some of the problems sighted above are due to the general verbosity of
LISP compared to APL; in particular, there is much greater proliferation
of functions in a large LISP system than one in APL because of the
difficuly of writing COMPACT one liners [just thow it in another function].

Also, note that I am not saying "use APL" rather, learn from the popularity
and usability of the APL environment.  LISP is better than APL for what we
do with it but I think that the environment needs work (and has for a long
time) and that it is about time someone did something about some of the
other problems in LISP as well.  NIL is the place to strike out at these.

-- Jeff Shrager