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

[Daniel L. Weinreb <dlw at MIT-AI>]

I generally agree with what Peter Deutsch said.  I would like to
point out some further things, regarding how these problems are handled
in the Lisp Machine programming environment.

The way files are used and the way the editor is used keeps user
functions conveniently grouped together and separate from system
functions; they don't get "lost".  In APL, if I load up a large package
of useful functions written by someone else, or by myself, then are
those "sytem" or "user"?  What if I am working on more than one thing at
a time?  An important part of the Lisp Machine design philosophy has
been to avoid the "system"/"user" dichotomy, so that there can be
programs that are shared by many users that are not necessarily in the
"system".

Indeed, nobody ever saves away Lisp Machine workspaces, and it might be
nice if you could.  But they are just too big to save in a brute-force
way, and too complex (and probably still too big) to try to save in a
clever way.  Actually, I have never found much need for this myself.

You are quite wrong about "cover functions".  Lisps are incompatible
because they are truly different; there are things you can do in one
that you cannot do in another.  Lisp has been growing and improving
at a tremendously high rate at MIT for the last several years; I have
no desire to stop this improvement by trying to crystalize a diamond
a la APL.

I am completely in favor of the verbosity of Lisp.  Lisp programs that
I am familiar with usually have the right amount of subroutinization.
APL is terrible this way.

I think Lisp has something to learn from APL, but it is mostly in
convenient handling of arrays that Lisp suffers, not in the programming
environment.