
Lisp OS: what has been lost: Kent Pitman - wglb
http://groups.google.com/group/comp.lang.lisp/msg/b2c0190dc30c3e5f?hl=en
======
raganwald
_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._

------
cpr
It's all true. I used LispM's in a previous life (running the MIT EE
department's computing resources in very early 80's) and there's no computing
environment within an order of magnitude of the power that Genera provided.

Kind of sad, really, but I suppose it's the kind of sadness that Smalltalk
mavens experience when looking at modern OO systems.

~~~
rbanffy
After getting started with OOP with Smalltalk and doing some stuff with Actor
(a Smalltalk with ALGOL-like syntax), it took me five years to seriously read
a book on C++ and another 7 to want to learn it. I only did it for the money.

And I still joke to my Java-loving friends how ST-80 made Java'09 look
primitive.

------
mark_l_watson
In 1982 the CEO and Treasurer of my company (SAIC) bought me a Xerox 1108 -
definitely a great box, especially because it was back in 1982.

Lisp purists will probably slam me for this (with adequate justification) but
I prefer the modern Lisp ecosystem with:

* both free/open source and commercial Lisp environments

* free deployment using open source systems like SBCL, etc. (In ancient history, I only used my 1108 for marketing prototypes and research because there was no reasonably priced deployment strategy)

* when I do want a persistent heap setup, I use SBCL and dump new images as I work. I don't often use this mode unless I have a lot of data that I am using over a long period of time - otherwise reloading source at the beginning of each work session is OK.

* emacs + slime is a good environment

If you want image based development, I would suggest that you try Squeak
Smalltalk (liberal open source license) or Cincom Smalltalk (modest cost, good
support and features, and a good deployment strategy). I think that using
Cincom is totally free until you start making money with it.

~~~
cpr
Except--no offense--the Xerox Lisp machine couldn't hold a candle to the MIT
CADR machine and its spin-offs (Symbolics/LMI) when it came to the development
environment.

------
rbanffy
I really wish someone starts selling MIT Lisp Machines built on FPGAs... They
would be the ultimate übergeek gift.

If someone wants to help me around with the hardware and software, I would
love to help building such an animal.

I suppose the Symbolics stuff is buried under tons of patents, IP and other
legal nightmares to be rescued right now.

~~~
asciilifeform
[http://www.unlambda.com/download/cadr/cadr_orig_verilog.tar....](http://www.unlambda.com/download/cadr/cadr_orig_verilog.tar.gz)

------
JulianMorrison
It was a one-true-language, one-user, no-process-isolation, whole-machine IDE
pretending to be an OS. With all the implied advantages _and_ disadvantages.
It would have been a nightmare on the modern internet. Root it and you could
rewrite _anything_.

~~~
Hexstream
I don't think all these cool features _require_ the system to be "one-true-
language, one-user, no-process-isolation".

Besides, when you're rooted it's game over _anyway_.

~~~
angelbob
It's harder for your debug environment to take apart and show the details of
every object down to the OS/hardware level if you've got security to prevent
it, and harder yet if it doesn't have a _very_ good idea of the specifics of
the binary representation.

We'd see this problem a lot with calling conventions (C-style vs Pascal-style
vs pretty much any weird thing you found a reason to do) if our gdb-based
debuggers tried harder to figure out what was going on. Luckily, they rarely
really bother and are wrong constant anyway about things like optimization --
they're built to do fairly little and live in constant confusion, so we don't
get that problem.

And for the record, I _like_ gdb and company. But every so often I get a wet
dream about being able to have a debugger that could show me useful
representations of objects and what they do. Things are better in Ruby-land,
but still not actually, like, good.

------
joe_the_user
It's (relatively) easy to write a GUI that puts all the information in the
machine "at your finger tips".

What hard and requires GUI designers _as well as_ programmers, is writing a
GUI that puts the _relevant_ information at the users finger tips in a way
that's understandable, that users can easily take-in.

Relevant, relevant, relevant! Understandable, understandable, understandable!

These are just two words but implementing them is a hard, cross-discipline
problem. What's telling is these consideration often don't even enter
programmer's discussions about GUIs.

~~~
wglb
Curiosity has the better of me: What other GUI puts all the information at
your fingertips besides the one noted here?

~~~
blasdel
Any modern Unix Shell -- just because they're character-addressed doesn't make
them not a GUI -- they have interactive screen-level features using curses. If
it wouldn't work via teletype, it's a GUI.

All of the state information is available via the filesystems (including
procfs/sysfs) and environment variables -- on a modern system you don't even
need to _exec_.

~~~
asciilifeform
> Any modern Unix Shell

Can I stop a Unix kernel, view + modify the line of source corresponding
_exactly_ to where it halted, and resume?

------
gwern
> 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.

He wrote all that in TECO? _What is wrong with this man?_

~~~
garnet7
I didn't understand that part of the post, but also don't know much of the
history here. Was Genera + Dynamic Windows running on these so-called "Lisp
Machines", or was it in competition with the Lisp Machines?

And if Kent was such a big fan of Lisp, why was he writing "impossible do on
Lisp Machines" programs in Teco? They could be written in Teco but not in
Lisp?

~~~
lispm
One branch of Lisp Machines originated at the MIT: the CONS and CADR Lisp
Machines. If Kent was at the MIT and was using Zmacs and ZMail, those ran on
the CADR already. Lisp Machines from Symbolics, LMI and TI were later based on
the hardware and software from the MIT, but they used new processors and the
OS was extended. MIT stopped developing the CADR and bought the machines and
software from TI and Symbolics, then.

Kent said that he implemented things in TECO that people thought were possible
only on the Lisp Machine. Writing software on the Lisp Machine was usually
easier than, say, in TECO.

~~~
garnet7
Thanks for the reply, lispm.

> Lisp Machines from Symbolics, LMI and TI were later based on the hardware
> and software from the MIT, but they used new processors and the OS was
> extended.

Ok, after some more reading, I think I'm getting the picture. Genera was the
OS on the Symbolics Lisp machines, and the MIT Lisp machines ran some other
similar OS. Genera's roots though were in the code from MIT.

> Kent said that he implemented things in TECO that people thought were
> possible only on the Lisp Machine.

Right. I don't get this. If he's a fan of Lisp machines, why bother spending
time implementing solutions to tough problems in TECO instead of whatever Lisp
his Lisp machines were running?

~~~
lispm
Genera was Symbolics' marketing name for their proprietary fork of the Lisp
Machine OS.

TECO was THE editor for years - on PDPs. Its macros look like line noise (if
you know what I mean). Emacs was 'invented' as a bunch of Editor MACroS for
TECO. Now comes a new generation of machines (personal workstations). Kent was
young and tried to show them that with software written TECO could do stuff
like Zmacs (the first Emacs written in Lisp) or Zmail (a Zmacs-based mail-
reader). TECO died anyway. The Emacs for Multics was also written in Lisp and
got popular among Multics users.

TECO was available for everyone who had access to a terminal that had some
connection to a PDP (or similar). The Lisp Machine OS had this $100000
hardware dongle - the Lisp Machine.

------
gcv
A few years ago, someone made a funny picture in response to a "which
operating system are you" quiz. The image showed Sir Alec Guinness as Ben
Kenobi, holding a lightsaber, and the caption said something like "You are
OpenGenera. Far less clumsy or random than Windows. An elegant operating
system, from a more civilized age." I tried searching, but can't find this
image anywhere. Anyone have a link handy?

------
jafl5272
Damn, I should have thought of "diff unsaved with what is on disk" a long time
ago.

------
wglb
This was linked to from a loper-os post, and I found it interesting enough for
a separate post.

------
phr
Someone in the thread mentions a plan that seemed inevitable at that time to
convert GNU emacs to the guile flavor of scheme. Obviously that never
happened. Does anybody know the story?

~~~
asciilifeform
AFAIK RMS nixed it.

~~~
garnet7
Why would he do that, given that Guile is GNU's flavor of Scheme?

~~~
blasdel
Guile had a bunch of intentions towards being a language-agnostic VM, a decade
before that was popular.

RMS has been deathly afraid of losing total control over developer tools --
GCC's whole architecture was purposely designed to frustrate anyone trying to
write out-of-tree code that handles/produces any of its internal
representations (which is why companies are pouring money into llvm/clang).
Imagine the bricks he would shit if emacs was a useful target for external
compilers!

------
snprbob86
Thanks to the modern web browser: we'll get a second chance at re-inventing
the fundamentals. As long as a machine can run webkit, even if it has to do so
inside an x86 emulator, that machine is useful for most people. The problem is
that to start from scratch requires a huuuuge stack of software, but you won't
be able to build at all at once. Well, now you don't necessarily have to.

------
j_baker
Heh... the title's kind of amusing. It made me wonder why Kent Pitman was lost
by the Lisp OS.

------
jacquesm
You have to be logged in to google groups to be able to read this.

~~~
gojomo
Not exactly... _if_ you're already logged into Google, _then_ they make you
re-login to Groups. If you log out of Google entirely, you can read it as an
anonymous visitor. In other words: they're only bugging people with login
prompts who they already know.

