A Story about Symbolics Lisp Machines
kremlin.enterprises
kremlin.enterprises
Actually, there was a rivalry with another company that's really worth mentioning, LMI (see https://en.wikipedia.org/wiki/Lisp_machine#Commercialization...)
"the amount of engineering effort that went into these machines far outweighs what you might get in a modern computer" - "the computer in front of you was probably purchased for a sum between $100 and $1000, and it represents $100 to $1000 worth of engineering. the kind of computer representing hundreds of thousands to millions of dollars of engineering are, well, pretty slick"
That's a pretty ridiculous comparison. The design of the intel chip in your cheap computer, and the fab process to manufacture it, really are worth billions. It's just automation and scale that brings the price down to a couple hundred.
In another case, Levy tells a story about a chess program with a bug in it. If I remember correctly, the program was in check, and moved a knight that didn't get the program out of check. In other words, it took an illegal move. Levy says the programmers were in awe of this program; wondering if it was inventing new rules to increase its enjoyment of chess. I have a hard time believing the programmers truly thought they had created a self-aware program that would modify the rules of a game to increase its own enjoyment. I'm sure they knew a bug when they saw it. Levy, on the other hand, apparently did not, or thought that his audience would overlook such a silly statement. I do blame the writer for that one, and wonder why the editor didn't flag it as well.
There are good books on computer history. And there are good books about computers from the early days (written in the early days). "Hackers" is not one of those books.
That's a tough question to answer. The universe is a big place, so i'm going to go with a lot.
Although, I do understand your annoyance. The original phrasing with the "in the world" is stupid.
* http://www.gnu.org/gnu/rms-lisp.en.html
* http://ergoemacs.org/misc/Daniel_Weinreb_rebuttal_to_stallma... (mirror of a blog post by Weinreb, made shortly after Weinreb died)
[0]http://fortune.com/2014/11/17/top-10-research-development/
[1]http://radar.oreilly.com/2008/10/linux-kernel-worth-1bn.html
The difference is like this: A 5 dollar plastic keyboard vs. a handmade $1000+ keyboard with mechanical switches.
The very first Lisp Machines were handmade $100000 pieces of hardware. With wire-wrapped boards made of zillions of low-integrated chips and various other components. Huge power supplies for several KW worth of electricity. Really everything was specially made, like 25m long console cables with signals for monitor, mouse, sound and keyboard.
Symbolics stuff isn't as rare as the post claims; you can still buy the Symbolics OpenGenera LISP environment for running on top of DEC's UNIX on an Alpha. [0]
In addition there's a port to x86-64 Linux floating around that lets you run it on top of a 2007-era Ubuntu in a VM [1]. There was also the MacIvory series of expansion boards that were a LSI-based Symbolics machine that you could fit in a Mac and run OpenGenera in a window.
Dave Schmidt at Symbolics was still selling hardware (a complete system could be had for under a couple grand) up until a couple of years ago; last time I contacted him he said hardware sales were now stopped so that what's remaining can be used for service/support contracts.
I bought a Symbolics keyboard from him before that happened and wired up an adapter using a Teensy to give it a USB interface.
I know of a company in College Station, TX that used a number of Symbolics systems when they were new, and the owner refuses to get rid of them because they cost so much new. A friend that worked there until recently ranted one day that they were using one of the chassis as a stand for the coffee machine, and I wanted to cry.
(disclaimer: I own/run http://www.lispmachine.net)
[0] http://www.symbolics-dks.com/
[1] http://www.cliki.net/VLM_on_Linux [2]
[2] http://weblog.mrbill.net/archives/2008/05/18/finally-got-ope...
I don't think this is still the case. I sent an email to their sales email address, and heard nothing. I also tried contacting their engineer, and even found the MIT email address of the current copyright holder nothing.
I also reached out to Peter Paine, but he only sells Symbolics hardware.
Is it still possible to legitimately obtain the software?
Symbolics, the company, made unreliable hardware. Too much wire wrap. 1983 was late to be introducing a wire-wrapped CPU. The Sun 2 and the Symbolics 3600 both came out in 1983, but the Sun 2 was a 680x0 machine with a printed circuit backplane and far less hand wiring, fixable by swapping boards. Symbolics machines had to be fixed by on-site Symbolics repair people, and the service was both poor and arrogant. This was at the height of the false AI boom ("expert systems") of the 1980s, and some people (I could name names on the Stanford faculty) were saying that strong AI was right around the corner. For a while, Symbolics machines were corporate status symbols. When that bubble popped, so did Symbolics.
Symbolics' original networking concept was that all machines would share some huge memory address space, with shared memory over Ethernet. That never really happened. They also really did have multi-hour garbage collections at first, until they got the garbage collector and the virtual memory to understand each other.
Most of those fancy buttons on the keyboard didn't do much of anything. SHIFT, CTL, TOP, META, SUPER, and HYPER were all shift keys, so there were 64 possible shifts for each key, any of which could be bound in EMACS. This was cool, but not useful.
Which is the verdict on the Symbolics machines - cool, but not useful.
The SUN 2 was a tiny machine in comparison. 1 MB RAM, 4 MB max. 16MB virtual memory.
> Sun 2 was a 680x0 machine
The Symbolics 3600 was also a 680x0 machine. ;-) It used one as its frontend processor.
> Symbolics' original networking concept was that all machines would share some huge memory address space, with shared memory over Ethernet.
That was never a part of the Symbolics operating system. Not sure where you got that from.
> until they got the garbage collector and the virtual memory to understand each other.
Which SUN never got.
> Most of those fancy buttons on the keyboard didn't do much of anything.
Actually they did.
> SHIFT, CTL, TOP, META, SUPER, and HYPER were all shift keys, so there were 64 possible shifts for each key
There was a logical system behind it and different shift keys were used for different purposes. Not all combinations were used. It's not too different from any modern computer. My mac has command, option, control, fn, shift keys. Five. The Symbolics keyboard had shift, control, meta, super, hyper. Five.
> So they were roughly comparable in memory capacity.
Sure not: you could use a 3600 with 20 MB RAM and 150 MB virtual memory.
There were a lot of Moore's law skeptics back then....
But... could one of you guys who knew the Symbolics machines help me out with something? What exactly made them so special, hardware wise? I mean, Lisp seems to run just fine on Linux on x64 hardware now. What advantage does one get from running Lisp on hardware which is custom tailored to it? Or would that even make sense nowadays IF something like the Symbolics Lisp Machines were still made?
tl;dr: They had special hardware that aided in dynamic language processing, like 40-bit words and hardware dynamic dispatch.
And it would not help you at all today because the most prohibitive part of the system is really the size of the CPU silicon wafer and its efficiency, and C is faster than Lisp and people are totally okay with writing code in it.
EDIT: RE: getting into Lisp in a big way: https://web.archive.org/web/20080709051856/http://www.lambda... tells you all you need to know. Specifically:
"And the problem with Lisp? The answer is tailor made for the minds who program it. It is the koan of Lisp.
"The answer is that there is no problem with Lisp, because Lisp is, like life, what you make of it."
Your Lisp code (unless it's an emacs tool) will never work with anything or anyone else. You're invited to write everything from scratch, and doing so is easy; it's just difficult for anything you do to be used by or with anyone else's code.
Lisp is so beautiful, and yet so dangerous.
Not really true these days, with the prolifiration of high-level-languages most libraries present a C interface which is no harder to bind to lisp than to other languages.
Since everyone else is jumping on this point, I might as well also point out that there are things like Chicken Scheme that actually transpile to C and are therefore compatible with it (and anything else that's compatible with C).
> and C is faster than Lisp and people are totally okay with writing code in it.
While C is indeed faster than Lisp (sometimes, at least; IIRC, some Common Lisp implementations like SBCL come within the same ballpark depending on the code being worked with), people are decreasingly comfortable with it as alternatives emerge and the cost of running a high-level language decreases (originally due to Moore's law, but nowadays also due to better-optimizing compilers and interpreters). I expect that we'll eventually hit a point where - much like how it's very difficult (if not borderline-impossible) to produce hand-written assembly that's faster than what a compiler will generate - it'll also be very difficult to write any sort of low-level code in a way that's faster than what a HLL compiler will spit out.
I wonder how the Lisp I'm using got its Cocoa user interface. Oh, it has an Objective C bridge, so that it can create natively looking Mac applications...
CCL is also not dead.
Firstly, computers back then were so much slower than they are now that the speed boost from running native versus interpreted is definitely nothing to scoff at.
Secondly, I now use StumpWM, a tiling window manager written in Common Lisp. This means I can connect to the lisp process that runs my window manager to inspect it, debug it, automate it, or make changes live. Now imagine you can do this with the entire machine!
Thirdly, and finally, not everyone is aware of the etymology of "car" and "cdr":
* car (short for "Contents of the Address part of Register number"),
* cdr ("Contents of the Decrement part of Register number")
* cpr ("Contents of the Prefix part of Register number")
* ctr ("Contents of the Tag part of Register number")
The original lisp implementation was on an IBM machine that had 36 bit words broken into 4 parts: the address register (15 bits), the decrement register (15 bits), the prefix (3 bits) and the tag (3 bits).
Lisp started out very close to the machine, for being such a high level language!
A million times this! Such a machine, end-user-programmable from the ground up, is a real 'bicycle for the mind'.
Which just means it's a doubly worthwhile project :)
But seriously, this is the promise of computing we're talking about. It had to be put on hold for a while, because when you're dealing with a resource-constrained machine like an early 8-bit micro, IBM PC, or Mac, you're going to have to ship tightly optimised binaries and use non-native dev tools.
So, given that no-one ships such a machine today, where are there priorities?
http://www.youtube.com/watch?v=o4-YnLpLgtk
pros: everything is lisp structure, no text serialization/deserialization to communicate between parts of the system.
cons: see above.
The glory days were not that glorious. There are stories out there of runaway garbage collections, that grinded on for days. Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built.
Rather, it's the spirit of the machines - inspectable and programmable from the ground up - that's worth preserving.
This is what made me curious about the Smalltalk-based Squeak VM http://squeak.org/. Its entire interface and stack was inspectable and manipulatable in real time.
In practice it seemed a little buggy, though. If you installed Squeak programs too willy-nilly, pretty soon you'd get errors due to incompatibilities.
Data structures are dictated by the requirements of what you're doing, not the machine. Linked lists are out? The C middleware that runs everything is full of "struct foo { struct foo * next; int other_field ... }".
Linked lists benefit from caching, like other kinds of data.
> Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built.
The garbage collection in your web browser is complete, utter garbage compared to what Lisp people were doing 30-40 years ago. Sorry!
(I will add to this comment later; I have to go to Task Manager and kill the web browser.)
Can you back that statement up? GC has advanced heavily over the years (and still is).The first paper on generational GC was published in 1984, and I would imagine that it has drastically improved since then. I don't think that generational GC even landed in SBCL until sometime around 2005.
Without anything to back that up, your post just sounds like Lisp fanboyism.
http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/s...
C datastructures most commonly used are Array of structs, Trees and Hashes. Linked lists are not commonly used I imagine. I don't have any stats to back that up though, neither did you.
Out for what?
> CAR/CDR? Let's not.
Works okay even today on a typical Intel 64bit processor.
> The glory days were not that glorious. There are stories out there of runaway garbage collections, that grinded on for days.
Maybe in the early days. Lisp Machine development started in the mid 70s and ended in the early 90s. In the later days its GCs (it provided several different, cooperating GCs) were quite sophisticated.
> Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built.
It won't. Browser GCs are actually not more sophisticated compared to a later day Symbolics GC. The language model of JavaScript is much more primitive than what ran on a Lisp Machine.
Lisp Machines had the same problem like we have today: a hierarchy of memory with different speeds. Very little 'fast' memory, and much much slower, but much larger, virtual memory. Actually the Symbolics Lisp Machines had pretty sophisticated GCs which you even won't find today on typical machines. Caching was all important on Lisp Machines and there was a lot done for that.
A typical Lisp Machine in the Mid 80s had something like 16 MB RAM and 100 MB or more virtual memory on slow disks locally or over the network. End 80s it was 40MB RAM and a couple of hundred MB virtual memory on local disks. Without effective caching strategies this would not have been useful. Some special machines had more RAM, but this was very very expensive.
These machines saved optimized images from which they booted. The memory was sorted according to object types into regions. Lists were converted into a vector-like representation (cdr coding), etc etc.
At runtime a copying GC would move objects around into generations with object-sorted regions, improving locality. An ephemeral GC tracks changed memory in RAM.
Additionally there were a lot of data structures which were under special memory management like networks packets or raster arrays.
EDIT: you seem to have posted a relevant link in another comment as I wrote this one, but I'd love more information if available.
Giving up on assembly language was the apple in our Garden of Eden:
Languages whose use squanders machine cycles are sinful.
The LISP machine now permits LISP programmers to abandon bra and fig-leaf.
-- Alan Perlis, Epigrams in Programming, ACM SIGPLAN Sept. 1982But not nearly as sinful as languages whose use squander human brain cycles.
I think it was Von Neumann didn't like assemblers because it was wasteful to use computers for such a mechanical process that cheap labor could do.
Edited: in fact, I started a project to implement a toy Lisp implementation on an 8-bit micro a few years ago. I'm almost at the point of giving up on the idea because it became quickly apparent that a less resource-hungry language would allow me to achieve more with the same hardware.
LISP 1.5[1] did run on a 704 which had only 4096 words, but that's in many ways unrecognizable as a lisp of today.
[edit] The 704 included up to 16384 words on the 733 magnetic drum (core was 4096), so that already is more space than what the parent has, and this is circa 1960!
1: http://www.softwarepreservation.org/projects/LISP/book/LISP%...
Yes, and then convinced ARPA to fund the purchase of 1 megabyte (MiB, of 9 bit bytes) of core memory, a full address space. At the edge of the state of the art back then, many people said it couldn't be made, and I seem to remember coming across some stories about it being quite difficult to get operating.
When I showed up in 1979 it was referred to with names like the "crufty", it wasn't all that reliable.
Those were original formula KA10s. Afterwards came a KI 10 processor I don't know much about, none were bought by MIT. For MIT-MC, David Moon modified the KL10 firmware to do ITS style paging.
Developing that KA10 paging unit must have been wild; a student run computer center I started inherited the hardware, and the schematics were fascinating, especially since they were from before there was a standard for logic gates. Instead, they were represented by boxes with the logic function marked in an upper corner.
A friend of mine (who I recruited into LMI and who put several "100 hour weeks" into successfully debugging and finishing their LAMBDA processor) noticed that in some cases the state of a gate, or perhaps a flip-flop?, was changed by hitting its output hard. Gates were sufficiently expensive, and the designers knew the hardware sufficiently well; you can see a picture of one 9 transistor Flip-Chip here: https://en.wikipedia.org/wiki/Flip_Chip_(PDP_module)
See Hackers, by Steven Levy, also some stuff in Wikipedia
https://en.wikipedia.org/wiki/Lisp_Machines
https://en.wikipedia.org/wiki/Symbolics
Had a summer job doing UI work on a Symbolics machine at MITRE, which was kind of like working in the future in summer of 1985... object oriented development, megapixel WIMP interface. I don't think Sun came close to that until UIM/X, Motif, PowerBuilder in early 90s, Visual C++, VB on PCs...like a 10-year head start.
But python especially feels like the revenge of Scheme and Lisp in the sense of being the same sort of dynamic interpreted language and environment where code is data, all the data and code (including libraries) are very accessible and amenable to inspection and tweaking.
He implied it by saying that code is data in Python. Being able to inspect code is not the equivalent.
It is also incorrect to refer to Scheme and Lisp as just dynamic interpreted languages; while they are dynamic and tend to have an interpreter they have also had compilers for quite some time if not from near the very beginning (1957 according to this http://www.softwarepreservation.org/projects/LISP/ibm/Blair-...).
Python doesn't feel to me like revenge of Lisp. It's more like having a shard of a powerful magic artefact; it has some power, but a whole artefact has qualitatively more.
Here's to the coming hardware revolution!
The 8086 was a 16-bit CPU, but you are correct that Lisp didn't run well on it.
Programmatically they were still 16-bit. But as an OS engineer, the 8-bit bus was very much evident when writing drivers, moving data, initializing memory etc.
For cases where DOS had used an instruction that would change, Intel rolled over and crippled that instruction in 16-bit machines (at least for a while) so it would behave the same.
The original Symbolics architecture ran some form of Lisp-firendly but not really Lisp instruction set. IIRC there were compilers from other languages targeting it too.
Also having the REPL act as shell, which meant any Lisp library on the system, or running application was exposed to the shell and could be manipulated.
Imagine having something like IPython or Swift Playgrounds as your OS shell.
Also the power of having an expressive power of language like Lisp for both systems and business application programming.
"...by someone who had hand-wrapped Z80 boards in the MIT AI labs at one point".
(Search the rest of the current discussion for "coffee machine" ;) )