[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sifting thru the "good mud": LISP vs APL
- To: shrage at WHARTON-10
- Subject: Re: Sifting thru the "good mud": LISP vs APL
- From: Jon L White <JONL at MIT-MC>
- Date: Tue ,11 Nov 80 14:50:00 EDT
- Cc: LISP-FORUM at MIT-MC, LISP-DISCUSSION 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...
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 ...).