Re: Sifting thru the "good mud": LISP vs APL

[Jon L White <JONL at MIT-MC>]

I'd like to offer some comments of the topic which Shrager brought
up last week, and except for "ditto"ing RMS's remarks about the
sensibility of labor division between EMACS and LISP, I hope these
will be points which others haven't yet brought out.  It's worth
noting that EMACS was brought up on MULTICS as a sub-system written
in MacLISP, and a similar effort is under way now to bring it up in
NIL (the NILE project, which is currently running to some degree on 
the NIL emulators of the PDP10).
    Date: 10 Nov 1980 (Monday) 0512-EDT
    From: SHRAGE at WHARTON (Jeffrey Shrager)
    Subject: Improving the LISP working environment by taking a lesson from...
    APL!
      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. .  .  .
      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 .  .  .
      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.  .  .  .
Re poinst (1) and (2), we have had in MacLISP, for about 8 years, a division 
of space into "pure" and "impure";  initially it was for the benefit of 
MACSYMA, and then for other "dumped-out" systems, so that as many as 
possible of the pages of the dumped-out system could be shared among 
simultaneous users.  This is not quite the same thing as the InterLISP
MAKESYS facility, which generally gives you copy-on-write access to most of 
the dumped pages, but is something which places a burden on the system-builder
to distinguish at load-up time between functions and data-bases which are 
essentially debugged, and those which are more volatile; redefinitions
don't cause "private" copies of pages, but do consume address space
since the pure stuff is never reclaimed.  Such a division has the happy 
consequence that a "check-point" dump need write out only the pages 
which are "impure", and that when such a "check-point" dump is restored,
it merely maps pages in (rather than trying to recreate the state of some 
workspace).  In fact, we have several systems here (e.g., NACOMPLR the 
"NIL-aided COMPLR", and BXOWL on the ML machine) which are several levels 
deep in a cascade of such dumpings.  That is, each level in the cascade 
causes to be dumped only the marginal difference between itself and the 
previous level;  at "restore", or start-up, time the deeper level will 
actually be mapping in pages from numerous files -- one or more files from 
each level in the cascade.  I may be wrong about this, but it seems unlikely 
that even a clever SYSOUT could do much better in terms of the size of the 
marginal dump file;  it certainly could not be faster.   Needless to say, we 
have similar facilities in NIL on the VAX.  The LISPM has an "area" facility, 
rather than a "pure" and "impure" space concept, and from one point of view, 
this is adequate, since it is not expected to have several simultaneous 
users of a dumped-out LISP subsystem.

This brings me up to point (3) -- LISP is too flexible.  Well, the blame
can hardly be laid at the feet of the language LISP, for its first 
incarnations were far too limiting!  In fact, the community which uses 
LISP is a highly innovative group, and the decision to use LISP as a 
systems programming language (by such a rapidly evolving community) may 
be what gives it its appearant instability.  When the data structures
of lisp proved to be competitively inferior, we extended them (fast
arithmetic in MacLISP, record-structured use of data in InterLISP and
now in MacLISP, character and bit strings, etc.);  when the control
structures left something to be desired, we added them (after many
groping experiments like MICRO-PLANNER, CONNIVER etc).  When SMALLTALK
showed us something new, LISP was our vehicle of choice in which to try
something new (CLASSes of LISPM, and the EXTEND of NIL over which a
similar CLASS heirarchy is built).  Deutsch hit the nail on the head
when he quoted Moses (approximately): "APL is a diamond -- you can't 
add anything to it, even another diamond, without ruining its beauty.  
Lisp is a ball of mud: you can keep adding more and more mud to it and 
its nature doesn't change."  It's this ability to absorb the "good mud"
of other languages which makes LISP so powerful and enduring;  it will
die if it ever fails to be "too flexible".

Lastly, I'd like to remind the community that LISP and APL are a lot
more alike, in a very crucial aspect, than this discussion would have
led one to believe.  What other languages besides machine language even 
admit dynamic variables (who cares if some pedagogical logicians lambast 
them as villains)?   How effectively do other languages/systems allow
you to have dynamic loading?  Sure, BASIC is interactive, but who will 
prefer it over APL or LISP (yes, Virginia, all prominent LISPs are 
interactive, not just ...).