[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving the LISP working environment by taking a lesson from...
- To: lisp-forum at MIT-AI, nil at MIT-MC
- Subject: Re: Improving the LISP working environment by taking a lesson from...
- From: SHRAGE at WHARTON (Jeffrey Shrager)
- Date: 10 Nov 1980 (Monday) 0512-EDT
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
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