Kent Pitman on what has been lost moving from Lisp Machines

Kent Pitman on what has been lost moving from Lisp Machines to Emacs / X Windows

Google Groups
More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...)))))
Kent M Pitman 	Feb 20, 1999 3:00 AM
Posted in group: comp.lang.lisp
cba...@2xtreme.net (Christopher R. Barry) writes:

> Within Garnet you can move your mouse over any object in your GUI and
> hit F1 to bring up the Inspector which gives you information about
> every single slot value in the object, displays it's "is-a" hierarchy,
> and shows you what things it's formulas depend on.

Within DW, you can move your mouse over any object or subobject
that has been displayed, whether or not it was part of any GUI.
You get this virtually for free and have to work hard to suppress it
if you don't want it.  But it doesn't require any special programming.

One of the most common ways to get a foothold in Genera for debugging
something is to (1) find a place where the thing you want to use
appears visually, (2) click Super-Left to get the object into your
hands for read-eval-print, inspection, etc, (3) use (ed (type-of *))
to find its source reliably and with no foreknowledge of what the
type is, who wrote the program, what their file conventions were,
who loaded it, or any of myriad other things that other systems
make me do.

> Under the X windowing system there is this standard tool "editres"
> that lets you click on any client and bring up it's class hierarchy
> tree and edit resources interactively.

Not resources.  Objects.  All objects.  Not just the heavyweight ones.
Lists.  Integers.  I somehow don't believe you when you say this is the
same as what Genera does.

The usual thing DW enables is the debugging of things that the
person did NOT make part of the standard interface.  Pointing to a UI
tool and saying it allows you to plan for structured debugging of
something is missing the point.

Or maybe you're saying that Garnet allows me to cross the boundary into
the internals of systems.  Maybe I'm missing out.

When you can make the claim that if you teach me a few paragraphs
worth of stuff, I will have all of the information I need in order to
bootstrap myself into a complete understanding of the entire operating
system and all of its conventions, I'll believe you Garnet and X are
as powerful as Genera and Dynamic Windows.  Until then, I'll continue
to believe they are different.  Incidentally, I'm dying to know that
there is a tool that will do all that Genera could do only for stock
hardware becuase the stack of books I need to buy in order to be
equivalently competent with other systems is daunting and I could
really do with the savings in time, energy, and money of learning things
about standard systems in the way I've been doing...

I don't even find Emacs itself to be equivalently self-documenting and
easy to get around in, much less the many systems that Emacs touches.

> I know these things aren't as cool as the LispM's equivalent, but is
> that it? It sounds like you have few nice applications that have
> functionality equivalent to modern environments but because of their
> tight integration you can do a few things that you otherwise couldn't.

Dynamic Windows offered a tight integration with the system.
You alleged that all that it offered is captured by Emacs.
The burden is on you to show that it is.  Defining away the problem
does not do that.

You haven't said how Emacs lets me "discover" systems.  You've only
said it provides tools that enable those who already know about a system,
and Garnet/X tools that let me inspect the formally presented UI of a
system.  That's not the same.

> > But for example, there's no assurance when I read in a source file
> > that it's the same source file that I loaded.  The lisp machine
> > keeps meticulous records not only of which source files are loaded
> > and from where but which functions have been patched by which files.
> > That means I can't make a mistake and use the wrong tags file or the
> > wrong version of files backing up a tags file.
>
> There are modern IDEs available for popular languages with powerful
> project file mechanisms with very similar capability. Not as cool, but
> still powerful and usable.

This started out by a discussion of what's cool.  You said Emacs was
cool and nothing else was needed.  Now you're qualifying your remarks
by saying everything is not as cool, and dodging the specifics I laid out.

> > There are myriad subtle ways in which Emacs is only a pale shadow of
> > Zmacs.
>
> Other than some of the cool functionality that arises within Zmacs
> from its super-tight integration with the rest of the environment,
> what can Zmacs itself specifically do that Emacs can't?

Paraphrase: "Other than the fact that the system you're talking about
involved a lot of people investing time and thought on various issues
that have been lost, can you explain to me why a system in which
that thought has been lost is deficient?"  Uh, ... no.  I can't.
This was about lost features.  This was about your claim that nothing
had been lost.  If you leave out the stuff that's lost, you're right,
there's no difference.

Look, I used to literally sit around in my office at MIT years ago and
fuss at people who said Lisp Machines were everything.  (I used and liked
Lisp Machines but I myself didn't think they were what they were because
of the hardware--they were what they were because of the software and
the ideas behind them.)  I used to ask people "What's an impossible thing
to do?  I'm looking for something to do this afternoon in Teco that people
say can only do on Lisp Machines."  People said Zmail.  I wrote the
approximate equivalent in Teco--filters, and all that.  They wanted a
filter menu.  I wrote that in Teco.  They wanted mouse handling.  (That
was tough because PDP10's didn't have mice, but I used my imagination a
little and arranged a mouse protocol from Lisp Machines so you could telnet
to the teco-based Emacs and click on my filter menus.)  They wanted
Zmail init files.  I wrote a Lisp compiler in Teco so that I could use
people's Zmail init files unmodified.  It was about 20K words of Teco
code, btw. Code was smaller back then... sigh.

Anyway, I *know* what it is to look at functionality and duplicate it
elsewhere.  It CAN be done.  I am not saying it can't.  What I'm
saying is that it has not been done, and it's a crying shame.  Few
people even know there ever WAS a lisp machine, and those who do are
mostly not rich enough personally to invest the time to duplicate what
was there.  Many people spent a big chunk of their lives investing in this
dream and it didn't pan out quite as we wish.  Ok.  Sometimes other
events win out--not always  even for the right reasons.  Or at least for
the reasons you wish.  But don't add insult to injury to say that the
losers in battles such as these had nothing to offer.

Common Lisp beat out Interlisp, and maybe for good reasons but it doesn't
mean Interlisp had nothing to offer--some very good ideas got lost in the
shuffle and I don't pretend that Common Lisp just obviously had a better
way.  Java is going to beat out Smalltalk perhaps, but that doesn't mean
Java is better than Smalltalk.  We owe it to the losers in these little
skirmishes to make sure that, if nothing else, the good ideas are not lost
along with the framework.  And we do not accomplish that by defining
that there was nothing lost.  That's both callous to those who worked
hard on these other things and short-sighted to the future, which might one
day care about the things that got lost.

There are still Lisp Machines around.  If you want to opine on them
with authority, get one and use it.  There is no substitute for first-hand
data in situations like this.


> > > And XEmacs can
> > > embed cool color graphics and glyphs/widgets into the frames to.
> > > Is there anything a programmer cannot do elegantly and efficiently
> > > within Emacs?
> >
> > In principle?  Well, it's all software.  You can make it be whatever
> > youwant, I guess.  But in practice, if you're asserting that Emacs
> > duplicates the features of Genera's editor, I think you're kidding
> > yourself.
>
> This functionality to click on an instance of any object seems really
> cool, and indeed Emacs as it is currently could never do this. But is
> that all? And again, this feature doesn't seem specific to Zmacs but
> rather Genera itself within which Zmacs is tightly integrated.

No.  It's not all.  I could enumerate any of a zillion things the
Lisp Machine editor system has that are not in Emacs.  But what would be
the point?  You'd see any finitely enumerable list, tell me it was all
stuff that could be done, and then say that my point was moot.

Here are a few, not intended to be complete, but to give you a spirit
of the degre of "precision" in Zmacs commands that distinguish them from
Emacs commands:

 * Tags Multiple Query Replace From Buffer

   This is an extension to Tags Multiple Query Replace (which does a
   multiple-strings-at-once Query Replace over a Tags Table; and,
   incidentally, the Tags Tables don't have to be files--the Lisp
   Machine just makes them up on the fly from spaces of buffers, from
   system definitions, etc. on user request).  It allows you to put
   pairs of elements and their replacements in a buffer and have
   all replaced in parallel.

   As with all operations of this kind (including Tags operations and
   other mapping operations like "Edit Compiler Warnings"), this creates
   a "possibilities buffer" which is a physical manifestation of keeping
   your finger on where you were in the middle of a complex operation
   so that if you see something else you want to do while you are
   doing the replacement, you can suspend the operation and resume it
   later perhaps after doing other replacements or edits.  When editing
   the ANSI CL spec, something I refused to do on anything but a Lisp
   Machine, I often had dozens of these buffers stacked up in simultaneous
   use and was successfully able to resume them to make sure all completed
   while allowing the system to accomodate my "focus".

 * Source Compare

   This command allows you to run a source comparision program (which
   itself is just presentationally way better than Unix diff or
   emacs compare-windows).  There was a public version of a source
   comparison program written by someone a while back that is as good
   but is in CL and isn't integrated into Emacs.  Alas.  But in addition
   to the presentational issues, which are comparatively minor, the real
   feature was how this could be called.  It prompts for two things
   describing what to compare, including "buffer", "file", "region",
   "definition", "top of kill ring" and "second in kill ring".  you type
   a single character (B/F/R/D/c-Y/m-Y) for each such prompt.  It's
   completely essential for comparing files.  What I can't comprehend
   is why no one thinks this is essential in a non-versioned file system.
   It's important enough in a versioned file system but in a non-versioned
   system one is always finding "probable copies" of files all over the place
   and trying to understand the differences.  Ready access to program
   controlled source compare is central to everything I do and basically
   wholly absent on stock hardware.  Another example is when you are saving
   a file on the lisp machine and you find it's been written by someone else;
   in emacs the query just tells you of a problem--in zmacs it offers to
   compare the files before making you decide whether to continue saving.

   It's not the feature itself, though that's important, but
   it's the attention to detail at this fine-grained level throughout the
   system which is why the lisp machine is so fondly remembered.

And that's my overall point.  It's not just about what's missing.
It's about the lack of interest in those who have created Emacs in
supporting those other things.  I still just use my Lisp Machine.
It's right here next to my PC, and on a regular basis I just move to
the other chair and edit in Zmacs.  6 years after heavy-duty
development ceased on Zmacs, it still whomps the competition and makes
me not care that processor speeds have gone up a zillionfold in the
meantime.  Others will tell you the same.

I WISH I could use features like that on a fast processor.  that would
be great.  But it isn't likely to happen soon.

You can say the burden is on us old-timers to tell you what's missing or
we shouldn't be whining.  But I don't see it that way.  I see the burden is
on the victors, who have the resources  and who claim their way is better,
to show us that they won for good reason.  We did our part for the cause.
We may or may not continue to try to do things to assure the ideas aren't
lost.

I spend a lot of my time trying to make sure old ideas make it onto
the books and don't get lost.  But I'm just one person.  It takes more
than one person.  And the task does not begin by dismissing the need
to do the job.

> > Also, I'm not suggesting this was a property of the Lisp Machine or of
> > special hardware.  Nothing the LispM did couldn't be implemented in
> > standard systems if people were of a mind to do it.  But they haven't
> > been, and it's historical revisionism to deny that stuff has been lost.
>
> Problem is, only people that have access to them know specifically
> what makes them cool. It's nice to hear from you what some of this
> functionality really is, but it seems that most of it is duplicated at
> least in part by some modern tools/environments.

You can order doc sets ... people give them away on this and other lists
periodically.

> > Also, I don't see how GNU Emacs Lisp could ever become CL-like, since
> > Stallman seems to control it and he doesn't seem to like CL.  I and
> > others fussed at him long ago when he diverged from CL.  It seemed to me a
> > conscious decision on his part to not care.  (Maybe even a good decision,
> > I'm not trying to moralize.  i'm just saying that the decision to be more
> > or less cl-like is a political one, and not a community one.  And for all
> > he talks about freedom for all, my impression is that he's very possessive
> > and controlling about these free things he makes, such that you have a pretty
> > severe obstacle to ever really changing it...)
>
> As I mentioned before, GNU Emacs is slated for Guile Scheme and
> nothing in the world can stop that. I remember some post from a guy
> that was working on getting lexical scope into GNU Emacs and the
> compiler but he said that RMS expressed reluctance in an email because
> the introduction of lexical scope would probably break some older code
> and in his opinion (I speculate) it must not be worth the effort to
> update older code to do the right thing in a lexical environment
> despite its advantages. I know GNU Emacs is kinda doomed in this
> specific regard, but XEmacs isn't. The developers are more open and
> have expressed interest in modernization to CL. For example, as of
> XEmacs 20.x the character-integer equivalence no longer applies and
> there are new data types like "character" and "char-table". There are
> functions like "old-eq" and "old-equal" that pretend that characters
> and integers are the same.
>
> Under GNU Emacs:
>
>   (eq ?A 65)
>   t
>
> Under XEmacs:
>
>   (eq ?A 65)
>   nil
>
>   (old-eq ?A 65)
>   t
>
> Now of course, we've got to get the "#" read syntax going so we can do
> #\A instead of ?A, and have the read-case uppercase symbols by default
> instead of doing everything case-sensitively, for starters....

I wish you luck in this regard.  These matters are syntactically small
and I don't really care a lot about them at the micro level.  But agreement
is important and Anything that unifies the Lisp communities is good.
"?" is a bad choice of character becuase it frustrates Scheme programs
who want to use "?" instead of "P" for the end of predicate names.
Even if one isn't going for Scheme compatibility, going for things that
don't creating gaping divides between the communities is good.

Previous post Next post