Interlisp

[Edward Barton <EB at MIT-AI>]

    [MESSAGE FROM KMP at MIT-MC  9:07pm]
    Interlisp is a total loss.

False.  Interlisp has a lot of nice features in addition to a lot
of lossage.  I think that simplistic thinking like the above is
rather silly, especially for a place that likes to think it has some
substance to its pursuits like MIT.

What you want to do is to copy or adapt the good ideas and leave the
bad ones, preferably after understanding what is right about the idea
and what exactly went wrong in trying to reduce it to practice.

I am reminded of a talk given by IBM research people at GM Research Labs
about their spiffy new editor/debugger thing which they were developing
for Lisp/370.  At several points members of the audience asked questions
about how one could do various things, and naturally it had never even
occurred to the IBM people that one would ever want to do such things,
even though the operations in question were clearly well-defined and
useful, and documented (although badly) in the Interlisp manual as
well as probably in other editors.  Of course the IBM people admitted
never even having read the Interlisp manual to see what its editor could
do, even though they were setting out on a major project with some overlap.
It was beneath them, I guess; better reinvent the whole world without
the benefit of looking at what people had tried before, and why, and
how.

I don't want to get into a big argument about Interlisp, but I will of
course continue to point out things that I personally have found useful
in working with large Interlisp systems.  I haven't suggested that the
Lisp community here should just adopt Interlisp, nor am I about to;
but neither am I likely to believe (or pay much attention to) blanket
knee-jerks like "Interlisp is a total loss."  Nothing personal intended to
anyone, of course, just a disagreement.  I might have a similar disagreement
with people that won't even listen to, say, CLU people.

And while I'm on it, why don't I point out another Interlisp winnage,
namely its iteration statements.  To me, at least, they are an order of
magnitude better than the idiotic Maclisp DO or the conceptually clear
(unless there are free variables) but (in my opinion) clumsy and ugly
MAPCAR, or MAPCONC, or MAPCADDADDRNCONC, or MAPCABBAGE, or whatever someone
wants to come up with next.  Of course that one's not much of an issue,
since PSZ has implemented similar Maclisp macros.