
Symbolics Lisp Machine Museum - rbc
http://smbx.org/
======
noahm
I used to work with a number of LISP machine believers at the MIT AI
Lab/CSAIL. They all had more modern computers for day to day tasks, but used
the lispm for most of their programming. This wasn't that long ago (I left in
2010), and I suspect that those machines will remain in active use for as long
as people can keep them running.

They all believed that the loss of the lisp machine was a serious loss to
society and were all very much saddened by it. I never used the system enough
to come to my own conclusions in that regard, but it was interesting food for
thought. As somebody for whom Linux/POSIX is very deeply entrenched, would I
even recognize a truly superior system if it was dropped in my lap? More
importantly, would society in general? The superior technology is rarely the
"winner"

~~~
gumby
It was by far the most productive programming environment I have ever used.
The level of integration of the editor, debugger, IO system, and interpreted
and compiled code is unparalleled. Interestingly it philosophically descended
from MACLISP development on a machine (PDP-10) that was designed with Lisp in
mind and that had an O/S (ITS) whose "shell" was a debugger, so you could also
do pretty tightly coupled development with EMACS (in TECO) and your code in a
mix of interpreted and compiled Lisp. In theory this deep level of integration
need not be Lisp-specific, but I haven't seen it that often.

The closest I've used were the three environments at PARC when I was there:
Smalltalk, Mesa/Cedar and Interlisp-D. When I use Xcode or Eclipse I feel
removed from the machine. In these other environments I felt simultaneously
able to think at a higher level and yet more tightly coupled to the hardware.

I've used various GNU Emacs modes and the coupling between them and the
runtime environment is not tight enough. Today I use SLIME+SBCL and it's OK.
It too lacks the tight coupling of the lispm. However for production we'll end
up re-coding in C++ for performance.

PS: A good friend of mine scorns the lispm-style of development as
"programming by successive approximation." There's some truth in that.

~~~
kjhughes
"Programming by successive approximation" is hardly scorn worthy in my mind.

~~~
gugagore
I too am left wondering, what is the alternative?

~~~
gumby
Well, with exploratory programming you tend to build up a couple of data
structures, add some functions to manipulate them, and then extend out from
there. In a more structured way you think up front about a lot more things. In
the second you probably doodle some stuff out on the whiteboard or on paper
before coding; in the first you probably simply start with an empty buffer
type straight into the REPL. There's a time and place for each and certainly
not a well-defined dividing line between the two (except in some highly
structured UML/TDD processes which may not even exist any more outside
aerospace).

For example I talked about the Lisp implementation of the code I'm working on:
for deployment it looks like it'll be be an implementation in C++ based on
what we end up learning about performance; certain implementation decisions
that were particularly good or particularly bad, or that we iterated on
several times before settling on something good; and that handles memory
management more directly.

------
lispm
For a very early overview of the technology I would recommend the 3600
Technical Summary. The 3600 was the first machine which was mostly designed by
Symbolics. It was followed by three more generations (gate array processor,
micro-processor and a virtual machine) of CPUs with something like 20+ further
models.

I once used a 3600. :-) It greets with "Yes, master" when you turn it on.

[http://bitsavers.trailing-
edge.com/pdf/symbolics/3600_series...](http://bitsavers.trailing-
edge.com/pdf/symbolics/3600_series/3600_TechnicalSummary_Feb83.pdf)

~~~
crististm
The alpha port that wanders on the torrents doesn't seem to have that. Either
I didn't see it or is it something specific to a particular version of 3600?

~~~
lispm
The 3600 is a physical machine, a computer with a cpu, memory, disks, tape
drive, lots of slots for extensions, network interface, console interface.

It has a display on the machine. That display shows the message.

------
qwertyuiop924
Symbolics made some really cool tech. I just wish everybody would stop
complaining about it. Yes, it was amazing. Yes, nothing modern can ever
compare, not even Emacs, an environment arising from the same culture. Yes, we
who experienced The Glory of the Lispm must eternally genuflect before it,
condescending to anybody who didn't.

Instead, go look at what Symbolics did (or try: it's quite hard to get the
emulator running), and learn. That system lost, and it's never coming back,
but you can learn from what they did well when building your own system.

But when you have, don't complain about the inferiority of our systems. It may
be true (I can't get the emulator running to find out), but it gets annoying
pretty fast. Take the energy you would use doing that, and put it into making
your system that much better.

~~~
lispm
You would not know that GNU Emacs has a shitty UI, if people would not tell
you.

> Take the energy you would use doing that, and put it into making your system
> that much better.

It's not easy, but people are/were doing it: CMUCL, SBCL, McCLIM, Mezzano, the
commercial Lisp systems like LispWorks and Allegro CL, ... all of them
were/are efforts to bring some of the ideas/features. People were even
developing emulators for the various Lisp Machines to make some of the old
software runnable. MIT open sourced their original Lisp Machine software.

One of the most important things currently is to preserve the history of these
and other machines / operating systems / applications. So that they are not
lost and people can study them and learn. Lots of stuff is already lost.

~~~
qwertyuiop924
I was plenty aware that Emacs had a crummy UI. I just don't think it matters
as much as you do. I said as much.

>It's not easy, but people are/were doing it...

That's actually great. I'm tremendously excited by those systems. I tend to
prefer Scheme to CL (less cruft), but I'm excited all the same. Those systems
and environments are really cool.

Although it _is_ telling that SLIME (which is excellent, by the way) is one of
the most popular ways to write Lisp code.

~~~
lispm
> I just don't think it matters as much as you do. I said as much.

There is a lot of software out there which needs powerful and/or different
IDEs to be written.

> Although it is telling that SLIME (which is excellent, by the way) is one of
> the most popular ways to write Lisp code.

Guess where the inspiration for some of the SLIME features is coming from...
Slime also does many cool new things, but it is still missing a lot of
features and usability from the old environments. Part of the reason is GNU
Emacs. It is what it is: a programmable editor with zillions of features. But
its base, its UI, its interaction model, its integration idea is limiting in
many ways. Many of the defining/leading IDEs were very different: Smalltalk
80, Interlisp-D, Symbolics Genera, ... Turbo Pascal, Visual Basic, Hypercard,
... NeXT ..., IntelliJ, ... (and a lot of others)

~~~
qwertyuiop924
I am well aware of where SLIME's inspiration comes from.

As for IDEs, I have a marked distaste for special purpose tools: I want to be
able to use on tool to edit all text. And not all IDEs are good: IntelliJ is
pretty rubbish (although that's more to do with Java than IJ itself...)

Emacs's limitations tend to line up with the length you can go before you
start becoming a special purpose tool, tightly tied to your environment, or
the point at which the Unix model doesn't really work, and you're going to
have to go build your own little world (like Smalltalk did). They certainly
aren't perfect, and could go a bit farther (something work _is_ being done on,
last I checked), but it usually works well enough, and it's so extensible, and
has had so many extensions written for it, that it can beat just about any
other general purpose editor, and sometimes even some of the special purpose
ones.

~~~
lispm
> I am well aware of where SLIME's inspiration comes from.

Obviously not. SLIME's inspiration comes from various other integrations of
Lisp into Emacs editors, especially Emacs Lisp and ILISP. SOME of its
inspirations comes from the Lisp Machine, direct or indirect. SOME. Not ALL
and not even MOST. For example the Lisp Machine does NOT use Zmacs as a Lisp
REPL, like ILISP/SLIME/... does. The Lisp Machine has a REPL, which is called
a 'Listener', which is a separate application and which is not based on a
Zmacs editor buffer. The Lisp Machine listener has a very different feature
set and look&feel, from an ILISP/SLIME repl.

The LispWorks listener is a mix of both: it is based on an Emacs substrate,
but offers slightly more Lisp Machine like interaction. SLIME though adds a
simple presentation system, which LispWorks does not use in the listener.

> I want to be able to use on tool to edit all text.

A Lisp system is not text-based.

Lisp is based on data. Code is data and data can be code.

Using an editor to work with text is only half of the story. A good Lisp IDE
lets me more or less directly interact with the data.

Interlisp-D worked with Lisp data throughout the IDE. That's a whole different
interaction.

> IntelliJ is pretty rubbish

It isn't. It's actually quite good at what it does.

~~~
qwertyuiop924
>Obviously not.

...And what makes you say that? I was actually aware, in any case.

>A Lisp system is not text-based.

>Lisp is based on data. Code is data and data can be code.

>Using an editor to work with text is only half of the story. A good Lisp IDE
lets me more or less directly interact with the data.

I'm aware of that, but text is a fairly convenient representation of Lisp
data. In fact, I'm unsure what you mean by directly interacting with the data,
as you can't have bytes fly from your fingertips, AFAIK.

In addition, files are a pretty good metaphor as well: If you want to store
your code as something textual, they're indispensible. And sure, you can use
image storage and navigate in other ways, but Lisp isn't Smalltalk: The way
Lisp is written isn't as unified, so that wouldn't work as well, AFAIK.

And sure, IntelliJ does what it does well, but I don't think that what it does
is especially good, and most of it is just making up for Java's sins, things
that don't exist in other languages: A good development environment is
imperative, but if it's painful to write code in the language without the
tools IDEs provide, than there's something wrong with the language.

~~~
lispm
> I'm aware of that, but text is a fairly convenient representation of Lisp
> data.

Some Lisp data does not have a textual representation, it might have a
graphical representation or the textual representation may not be very helpful
(Lisp data being a graph might be better displayed as a 2d or even 3d graph,
than as a textual representation). The Symbolics UI of the REPL/Listener would
allow you to interact with the 2d/3d graph as it were Lisp data, which it
actually is underneath.

> In fact, I'm unsure what you mean by directly interacting with the data, as
> you can't have bytes fly from your fingertips, AFAIK.

GNU Emacs pushes characters around.

S-Edit manipulates S-expressions.

GNU Emacs lets you pretend that you edit s-expressions, by pushing characters
in a buffer around. But you don't. All you do is push text around.

S-Edit directly manipulates the data. It's a structure editor.

Symbolics Genera uses 'presentations' to record for every output (graphical or
not) the original Lisp data. When you interact with the interface, you
interact with these data objects. For example in a Listener (the REPL)
programs and the Listener itself display presentations, which then can be
acted on. It also parses text into data objects and then runs the commands on
the data objects and not on text.

SLIME provides a very simple and partial reconstruction of that - which is a
nice feature.

> In addition, files are a pretty good metaphor as well: If you want to store
> your code as something textual, they're indispensible. And sure, you can use
> image storage and navigate in other ways, but Lisp isn't Smalltalk: The way
> Lisp is written isn't as unified, so that wouldn't work as well, AFAIK.

Smalltalk does not use data as representation for source code. It uses text as
representation for source code.

Interlisp-D is more radical than Smalltalk 80. The Smalltalk editor edits
text. The Interlisp-D editor S-Edit edits s-expressions as data.

Interlisp-D treats the files as a code database similar to Smalltalk, but the
source code loaded remains data and you can run the program from that data
directly via the Lisp interpreter. Smalltalk execution does not provide
something like that. The so-called interpreter in Smalltalk executes bytecode.
This is different from a Lisp interpreter, which works over the Lisp source
data.

The combination of a s-expression editor with an s-expression interpreter
(plus optional compilation) is very different, from what Smalltalk 80 did.

When you mark an expression in Smalltalk 80 and execute it via a menu command,
then the expression gets compiled to bytecode and the bytecode interpreter
then runs it.

If you mark an expression in S-Edit, the s-expression data is extracted from
the data structure you edit and you can run that s-expression data with an
interpreter, walking directly over that s-expression data.

~~~
gumby
BTW while pretty much every Interlisp-D user used D-edit, I was never
comfortable with it because it required use of the mouse. By the time I
started using Interlisp I had about six or seven years of Emacs wired into my
fingers and didn't like being slowed down by taking my fingers off the
keyboard.

There was an emacsy interface made by Kelly ??? in the office next to me which
I extended into a real Emacs clone (with modes and everything) which a bunch
of us used. In retrospect I should have gone native and adopted D-edit
directly but what can I say I was a snot-nosed 20 year old kid.

~~~
qwertyuiop924
That's probably what I would have done. But I'm a snot-nosed 15 year old kid.

------
DigitalJack
I get the nostalgia for these machines. I have great nostalgia for my old
computers, the ones I learned on.

I have watched some videos of open genera. I don't see the appeal. It was neat
for the time, but I have a hard time seeing what problems it solves for today.
I'm not trolling, if someone can give some specifics, I'd be interested to
read them.

------
starseeker
Wonder if there have been any updates since this:

[https://www.reddit.com/r/programming/comments/1a4wvf/kalman_...](https://www.reddit.com/r/programming/comments/1a4wvf/kalman_reti_the_last_symbolics_developer_speaks/)

------
protomyth
Who actually owns the Symbolics IP these days? I still wonder if it would be
possible to put a 3600 on a chip.

~~~
gumby
I heard rumor that JCMA had bought it. I'll ask him.

------
Animats
I used the Symbolics refrigerator (the 3600) briefly, but found Franz LISP on
a Sun II more useful. But then I'm not into editing from a control break.

------
jmorrison
I have an old MacIvory (Symbolics board set housed in a Mac II) which doesn't
want to boot anymore. IIRC Googling indicated that the Mac IIs are like cars -
they won't turn over if the motherboard battery is dead. I changed the battery
- no joy. Anybody have any recommendations, whether for a repair place (New
England, USA) or further DIY things to try?

------
catpolice
We have one of these sitting in the lobby at my office, used as a coffee
table.

~~~
mordocai
If it is functional(and maybe if not), you can potentially get a decent amount
of money from selling that.

~~~
yomly
Well it certainly isn't imperative!

~~~
qwertyuiop924
...yes, it is. Lisp is a multiparadigm language. Most lispms where programmed
using a mixture of OO and procedural code, with a bit of FP here and there.

