
Ergonomics of the Symbolics Lisp Machine - BruceM
http://lispm.de/symbolics-lisp-machine-ergonomics
======
crististm
I've managed today to boot OpenGenera in a Linux VM. It took me a couple of
weeks but it finally works. I intend to have a look myself at what the fuss is
all about.

If you're interested, here are some pointers to relevant resources
(snap4.tar.gz image works as advertised):

[http://www.advogato.org/person/johnw/diary/12.html](http://www.advogato.org/person/johnw/diary/12.html)

[http://www.cliki.net/VLM_on_Linux](http://www.cliki.net/VLM_on_Linux)

[http://libarynth.org/vlm_on_linux](http://libarynth.org/vlm_on_linux)

The opengenera tar-ball can be found in the intertubes.

Tip: Use Ubuntu 7.04 x86-64 to save you some trouble. I don't know what is the
most recent distro that works but 10.10 doesn't. You get a blank window
because recent X servers are missing something. Before proceeding with the
installation, complete the Ubuntu image with relevant archive server URLs to
be able to apt-get with ease.

~~~
segmondy
What's the fuss all about? A lot, but please bear in mind the time this was
developed. We are now in 2014. We are talking about something about 30 yrs
old. A good way to really compare is to go compare with an Apple ][.

~~~
EdwardCoffin
It certainly should not be compared with an Apple ][: the last Symbolics
machine was introduced in 1992, the NXP1000. They were still adding features
and such at that time, and the Apple ][ was long obsolete at that time.

There are some enlightening comments from Kent Pitman on comp.lang.lisp, which
give a sense of what kinds of features the Lisp machines provided to
developers, and why they still haven't been matched by contemporary systems:

[https://groups.google.com/d/msg/comp.lang.lisp/XpvUwF2xKbk/o...](https://groups.google.com/d/msg/comp.lang.lisp/XpvUwF2xKbk/o6CKxgzNLFUJ)

[https://groups.google.com/d/msg/comp.lang.lisp/XpvUwF2xKbk/X...](https://groups.google.com/d/msg/comp.lang.lisp/XpvUwF2xKbk/Xz4Mww0ZwLIJ)

------
jf
I own a Symbolics Lisp Machine (a MacIvory). I'm in San Francisco and would be
happy to show it to anybody who's interested and in the San Francisco Bay
Area.

Be warned, I'm still learning how to use Genera, so we'd be learning how to
use the system together.

------
cpr
The _real_ ergonomics of the LispM were due to the wonderful Microswitch
keyboards, which have never been equalled since. To use one was a kind of
revelation into the the apotheosis of keyboard use.

(The old, original Tom Knight AI Lab keyboards were even slightly more
wonderful; the later Microswitch LispM keyboards never quite equalled the
originals in terms of tactilely satisfying feel.)

(For a long while after leaving MIT (ran the MIT-EECS LispM and DEC-20
machines) I used one of the custom-made Lawrence Livermore run of Microswitch
keyboards, driving a custom 68K board which turned the up/down events into
standard RS-232 for use with standard CRT terminals. I think I still have that
keyboard somewhere in the now-long-abandoned kids' play junk.)

~~~
ScottBurson
Those were nice keyswitches, but the modern Cherry MX is also excellent. I
would be hard pressed to pick a favorite between the two of them. The Cherries
have a lighter touch and a little "snap", both of which I like.

~~~
seanmcdirmid
I'm still going on a vintage Model M. Heavy touch, satisfying clank on each
stroke.

~~~
gcb0
model m is overrrated amd loud.

cherry stopped in time.

alps lowered standards to fight off bad income.

...good switches help you feel the key and avoid bottom out. i personally like
old complex alps, but everyone will like something different.

~~~
hga
" _good switches help you feel the key and avoid bottom out_ "

To deal with bottoming out, using Cherry Blue switches, I've found that these
red dampeners work very nicely:
[http://www.amazon.com/gp/product/B00AZQ3966/](http://www.amazon.com/gp/product/B00AZQ3966/)
There are also thicker ones that have better stocking:
[http://www.amazon.com/Cherry-Rubber-O-Ring-Switch-
Dampeners/...](http://www.amazon.com/Cherry-Rubber-O-Ring-Switch-
Dampeners/dp/B00AZQ2OF8/) and the same company has a nice key puller:
www.amazon.com/gp/product/B00AZCGF7K/

~~~
gcb0
lol at mechanical keyboard related stuff prices.

i bought the same orings (internal, external diameter. hardness) from a
hardware store. paid $3.78.

...and you linked to the cheap ones :)

------
mehmetemre
> It was completely programmable with all source code. It was also not for
> 'playing' around - for that it was too expensive. As a software developer
> you could focus on your task and the whole operating system was supporting
> you. There was no piece of software that was not accessible in a few mouse
> clicks. Everything could be inspected, everything was up for modification.
> Software was live and dynamic. Not dead and static like today. There was no
> boundary between software development and software usage.

This reminds me of Smalltalk environment like Pharo. I recently realised that
there were so much things in common between Lisp and Smalltalk environments
(by Lisp environments I mean what we have today like SLIME+Emacs or
LightTable). I also think that LightTable has a huge potential for being a
successor of Lisp machines and _really_ integrated development environments.

~~~
lispm
Pharo runs on top of something, running on top of something else, ...

Genera on the Lisp Machine runs on the metal. It is the process scheduler, it
does handle the bus interrupts, it receives the network packets, it writes the
bytes to the disk controller, it sets the bits in the graphics card, it writes
the sound bytes to audio interface, the network packets are Lisp arrays, ...

~~~
cpr
Yes, but don't forget the microcode level that runs the Lisp code. Some very
small bits of the OS were written in microcode (as few as possible), IIRC.
(It's been a long time since I was hanging around the AI Lab. ;-)

~~~
lispm
The processor instruction set was implemented in Microcode. It was optimized
to run compiled Lisp code. There was also a Lisp to Microcode compiler, though
I haven't used it.

~~~
rjsw
The microarchitecture of the MIT/LMI/TI machines wasn't particularly
complicated, it had pipelined 3-address load-store instructions just like the
first RISC CPUs. Apart from the functions to handle each Lisp instruction the
microcode was basically a simple RTOS. In my view, the clever part of the
design was in picking the minimal features needed from the microcode to allow
everything else to be writtin in Lisp.

There was a proposal from Sun for a Java OS that seemed to me to copy the same
split.

It is a pity that all the Ivory papers that were in journals still seem to be
behind paywalls.

------
owenversteeg
Site's down, here's a pastebin of the text:
[http://pastebin.com/6kkCTgjg](http://pastebin.com/6kkCTgjg)

Neither archive.org nor Google Cache have this. Weird.

Video from article: [http://vimeo.com/83886950](http://vimeo.com/83886950)

Image 1: [http://i.imgur.com/r62FSfE.jpg](http://i.imgur.com/r62FSfE.jpg)

Image 2: [http://i.imgur.com/xsxutc3.png](http://i.imgur.com/xsxutc3.png)

Image 3: [http://i.imgur.com/zL9DFbr.png](http://i.imgur.com/zL9DFbr.png)

~~~
zokier
> Video from article: [http://vimeo.com/83886950](http://vimeo.com/83886950)

The things that stood out to me were that a) boy, it was a slow system. Sure
vi etc are more spartan, but even back then I'd imagine the were significantly
faster than this Lisp machine. b) mouse was clearly the hot new thing, it is
used lot more than what I think would be optimal.

~~~
lispm
That was a 5 MIPS machine with just 40 megabyte RAM. The UI ran over a 10
Mbit/sec Ethernet X11 connection on a remote machine.

~~~
zokier
I suppose I meant that they probably were bit ahead of their time and overly
ambitious. Performance and especially latency are critically important for
interactive applications. The designers must have been fully aware of the
performance characteristics and hardware limitations at the time, but still
they decided to ship such system. Maybe they should have taken a look in the
mirror and notice that the hardware is not ready for what they were making and
downscaled it to fit, then incrementally grow those features back when they
become more practical.

~~~
lispm
The goal was not to have a fast vi, for writing applications in a slow way. If
you wanted vi, there were other systems.

It was a system for research of development of advanced software, often with
complex GUIs. Symbolics sold for several years into the CAD and 3d-graphics
markets.

------
eudox
Related: A huge collections of images showing Symbolics UI and the software
written for it: [http://lispm.de/symbolics-ui-examples/symbolics-ui-
examples....](http://lispm.de/symbolics-ui-examples/symbolics-ui-
examples.html)

~~~
agumonkey
Nice, but I wouldn't confuse static images with the underlying semantic graph
of live objects that's not visible in pictures.

~~~
DonHopkins
Precisely! When Lisp Machine programmer look at a screen dump, they see a lot
more going on behind the scenes than meets the eye.

I'll attempt to explain the deep implications of what the article said about
"Everything on the screen is an object, mouse-sensitive and reusable":

There's a legendary story about Gyro hacking away on a Lisp Machine, when he
accidentally trashed the function cell of an important primitive like AREF (or
something like that -- I can't remember the details -- do you, Scott? Or does
Devon just make this stuff up? ;), and that totally crashed the operating
system.

It dumped him into a "cold load stream" where he could poke around at the
memory image, so he clamored around the display list, a graph of live objects
(currently in suspended animation) behind the windows on the screen, and found
an instance where the original value of the function pointer had been printed
out in hex (which of course was a numeric object that let you click up a menu
to change its presentation, etc).

He grabbed the value of the function pointer out of that numeric object, poked
it back into the function cell where it belonged, pressed the "Please proceed,
Governor" button, and was immediately back up and running where he left off
before the crash, like nothing had ever happened!

Here's another example of someone pulling themselves back up by their
bootstraps without actually cold rebooting, thanks to the real time help of
the networked Lisp Machine user community:

ftp://ftp.ai.sri.com/pub/mailing-lists/slug/900531/msg00339.html

------
wilfredhughes
I'd love to play with a Lisp Machine. I live in London, UK, so sadly I can't
see any way of using one (either a physical device or a VM). There are pirate
copies, but I don't want to go that route.

What lisp machine articles often miss is contrast to other related projects.

Complete introspectable systems: How does the experience compare with using
Pharo Smalltalk today? Sure, it doesn't provide a kernel, but it's a pretty
complete* system that's very reflective and open to modification.

Running a lisp userland: There are Common Lisp replacements for Emacs, CL
window managers, and one or two Lisp Machine style GUI libraries (CLIM).
However, most Lispers seem to be happy using other WMs and Emacs. Do the CL
applications miss something that the Lisp Machine environment provided, or
were the alternatives more compelling somehow?

Other Lisp Machines: The MIT CADR is open source and available online[1]. Lisp
Machine articles seem to focus on Symbolics software, what is that the CADR
lacks? rms allegedly reimplemented many Symbolics features on MIT Lisp
machines.

I'm often struck by how many Lisp Machine features have been implemented on
other systems (e.g. CLIM, versioned file systems) yet haven't gained many
users. There must be stories here.

1: [http://www.unlambda.com/cadr/](http://www.unlambda.com/cadr/)

*: Of the developers I've met, Emacs hackers seem to live in Emacs more than Smalltalkers in their image. For example, there are multiple Emacs twitter packages, but I've not seen any applications (only libraries) for tweeting from inside a Smalltalk image. I'm not sure what this says about the respective environments.

~~~
lispm
> How does the experience compare with using Pharo Smalltalk today?

Genera is a full operating system running directly on Lisp Machine hardware. A
CPU which runs a stack machine. The network code goes down to the packets and
the Ethernet card driver.

> There are Common Lisp replacements for Emacs, CL window managers, and one or
> two Lisp Machine style GUI libraries (CLIM).

A few thousand developer years is the difference. Sophistication. Polishing.
Applications.

> rms allegedly reimplemented many Symbolics features on MIT Lisp machines.

He didn't. He tried to help LMI, but stopped soon. Symbolics, LMI and then TI
developed a lot of more software. Much more.

> I'm often struck by how many Lisp Machine features have been implemented on
> other systems (e.g. CLIM, versioned file systems) yet haven't gained many
> users. There must be stories here.

Versioned file systems existed before and after Lisp Machines. For example
DEC's VMS had a versioned file system. CLIM was the attempt to develop a
portable standardized version of the GUI library of Symbolics. It failed to
gain real traction: too different, not very polished, everybody had already a
different GUI toolkit, ...

Here is an example of using a high-end Lisp machine application for 3d
graphics:

[https://www.youtube.com/watch?v=8RSQ6gATnQU](https://www.youtube.com/watch?v=8RSQ6gATnQU)

[https://www.youtube.com/watch?v=6VmJVNYfxDc](https://www.youtube.com/watch?v=6VmJVNYfxDc)

------
pjmlp
Sometimes I wonder how much better the computing would be if Lisp Machines had
succeeded in the industry and UNIX never left the lab.

~~~
happycube
Considering most of the Internet was developed under UNIX machines, the
alternate universe would be almost unrecognizable, for good or bad.

~~~
ChuckMcM
It is a bit more nuanced than that, ARPANet was a lot of DEC machines, USC and
USC-ISI had a number of DEC-10's on the network. Usenet was however primarily
a bunch of UNIX (or UNIX like) machines. They traded in their modems for nifty
connections to the Internet and carried a lot of the same protocols with them.
Much of the Internet protocols were developed in college labs with the ability
to 'plug in' different UNIX configurations (the BSD sockets stuff) and since
the code was tested well on UNIX was often the operating system on the machine
that connected someone to the emerging Internet at the time. Lisp systems were
popular for research, but were not used extensively for networking research. I
expect it was in part a compatibility issue with BSD's socket stuff (where a
lot of research was happening).

A more interesting alternate history for me would be if the folks doing system
research had settled on a functional language like Haskell rather than a
procedural one like C, what would our APIs look like today. I say that because
I suspect that using C as a the language of choice was more influential than
the OS of choice.

~~~
lispm
Lisp Machines were usually networked machines. Their were two branches:

* Interlisp-D from Xerox were smaller machines, networkd with a server + printer. PARC developed networked collaborative software for them, the first remote GUI was written for Interlisp, the first IMAP client was written for Interlisp-D, ...

* the MIT Lisp Machines were developed with CHAOS, an Ethernet-based protocol. TCP/IP was available early. Many of the TCP/IP protocols were implemented for them (often client and server): chat, terminal, mail, RPC, NFS, X11, DNS, HTTP, remote printing, remote booting, ... They also ran DECNET and some IBM network protocol. Actually the networking code from Symbolics was quite sophisticated in some respects...

BBN (the Internet company at that time) also used a lot of Lisp Machines. They
had some distributed remote object networking substrate, which also ran on
Lisp Machines.

Lucent had developed an ATM network switch, which first versions were based on
multiple embedded Lisp Machine boards for the switching code and another Lisp
Machine for the control and administration. They ran all kind of fancy
networking code on them in a zero downtime fashion with live software
upgrades. They were for example thought as large network and telephony
switches.

~~~
gumby
One small correction: the D machines weren't all smaller; there was the
Dandelion (later sold as the Star), the Dolphin and the Dorado (which was a
full rack, the size of a 32-bit CADR machine, and built of ECL logic). There
were at least three different standard microcoded environments you could boot
with, Interlisp-D, Smalltalk and Mesa. When I was at PARC if I worked late I
could connect to a Dorado, but most of the time I used a Dolphin (plus my
group had some Dandelions which ran some custom microcode). They could also
run Alto microcode by the way.

I preferred the MIT lispm environment better because I grew up with it. For a
while I had a job where I had both a dandelion and a 3600 in my office; later
I had two 36xx machines, one with a color display.

They were pretty fast for their time. The late, hyper-dynamic window system
was probably too heavyweight for its time, especially when later translated
over X, but I generally used the simpler base window system because it was
faster.

It was the most productive (in terms of amount of useful code generated per
unit time) system I have ever used and I still miss it. The Interlisp D,
though quite different to use (and in some ways better), is a close second.

~~~
lispm
Right, but the large one weren't sold, IIRC. Xerox sold the smaller ones, not
the Dorado. That was also why some users upgraded to the Lisp Machines from
LMI, Symbolics and TI: they had larger address spaces and could run larger
software.

------
bane
Out of curiosity, what were things that these systems did poorly or that we
know not to do these days?

~~~
ScottBurson
Security was literally nonexistent. If you were at the console, you had
control of the machine. Pwning one over the network was probably not
difficult, though it wasn't the kind of thing people spent much time on back
then.

~~~
cturner
Is that a bad thing? I wonder sometimes how much we lose in develop
collaboration due to security layers. I can imagine running a cool multiuser
image in a prototyping language like to.

~~~
bitwize
If security is important, you lose something in terms of getting shit done.
It's up to you or your organization what the tradeoff is. Fun fact: At one
company I worked at, it was a matter of security policy that every machine in
the company run the Bit9 binary whitelisting software. Every. Single. One.
Including all the dev machines. In addition, it was decided that valuable
corporate assets such as source control be airgapped from the outside network,
making it difficult to run a dev machine that could access both the repo and
the Web where all your documentation is. But Security was determined to be
Priority One at that company, so productivity had to take the hit. If you
develop the tech ten times slower and with ten times greater annoyance to your
engineers, that was a worthy price to pay for not having it stolen by scary
foreign spear phishers.

------
pnathan
What kind of systems today in the software development field are produced by
experts for experts?

The only ones I can think of are languages like C++ or Rust. Perhaps emacs and
vi...

~~~
catenate
I use Inferno to develop software, as a virtual OS over top of Linux or
Windows. Its community doesn't see any value in writing software just to make
it easy to use for newbies. It is still actively maintained, with new changes
from Plan 9 development. There are even some new software tools developed in
it (eg, I wrote a build tool). Maybe this qualifies?

------
endlessvoid94
seems to be down, does anyone have a mirror?

~~~
eudox
Neither the archive nor Google Cache seem to have it.

~~~
edwintorok
I tried web.archive.org/save/[http://<url>](http://<url>), but I got 'Access
Forbidden for URI [http://lispm.de/symbolics-lisp-machine-
ergonomics'](http://lispm.de/symbolics-lisp-machine-ergonomics'). The site
itself loads fine in both firefox and chromium, but doesn't work with
wget/curl. Probably some protection against robots / automated downloaders.

------
madengr
"It was also grounded in the believe that software development is best done by
small groups of very good software engineers working in a networked
environment."

Wow, what a quote. Now can we repeatedly beat that into management's head.

------
gcb0
that keyboard, along with the space cadet one, is an aberration.

It is too complex for novices, with too many keys. And not optimal to the
initiated, as key combinations are much more efficient.

anyone with the slightest ergonomic knowledge cringe just by glancing at those
things.

~~~
qbrass
Both that keyboard and the space cadet have fewer keys than an IBM PC
keyboard.

~~~
gcb0
1\. thats a straw man argument. the keypad, etc do not count much.

2\. i never said the ibm pc keyboard was any god either :)

