Lisp OS: what has been lost: Kent Pitman | Hacker News Reader

Lisp OS: what has been lost: Kent Pitman

groups.google.com

75 pointswglb45 comments

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.

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.

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.

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.

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.

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.

http://www.unlambda.com/download/cadr/cadr_orig_verilog.tar....

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.

You could make a similar argument about DOS. Which is a shame.

EDIT: Except for the whole-machine-IDE thing, obviously. Although if you wanted to hand-hack assembler, you could, as far as I remember.

What Assembler? It didn't come with one, and what do you need mnemonics for anyway?

You programmed in the absolute using the alt-numpad method to input arbitrary bytes, at least to bootstrap yourself.

http://en.wikipedia.org/wiki/Debug_%28command%29

Yep, that's what I was trying to remember.

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.

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.

Sure, but look at the MIT AI Lab environment from whence it sprang: their PDP-10's ran ITS (the Incompatible Time Sharing system, a jab at the IBM 7090-based Compatible Time Sharing System, CTSS), which was a completely open system. Anyone could create an account, and anyone could bring down the system with a few keystrokes (the terminal interface was an extended DDT, a single-keystroke-command-style debugger), and anyone could delete any file, including system files.

They had a radical open system, and defended it (yes, it was early in the life of the ARPAnet/Internet) with great backups and social pressure.

The LispMs were not much different.

I don't think that would make sense nowadays. Great backups are good to have, but they aren't a panacea. And I could just imagine how social pressure would work: "Hey guys, please don't exploit this bug in my webserver that will make it reformat the hard drive"

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.

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

Regedit and bsh

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.

> Any modern Unix Shell

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

By "all the information at your fingertips" i meant the things that Genera can do. So you look in /proc/core and find the bytes, but it won't show you the source that produced that, or even the program. The Unix Shell and curses doesn't cut it.

Take a look at this stackoverflow question: http://stackoverflow.com/questions/238177/worst-ui-youve-eve...

Notice something? Poorly designed UIs tend to cram every bit of information as densely as they can.

Are you saying that the Genera interface is badly designed?

I was only saying that in discussion of Genera, the only argument for Genera's superiority was how much information it presented. I've never Genera's interface but the criteria of amount of information presented seemed a bit off.

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

I don't think so. In most cases the relevant information doesn't even have a formal representation (ex: it's "hidden" in turing-complete code) at the application level so it's literally impossible to get at this information unless you rewrite that application. What you need is support from the OS that lets you write "semantics-preserving" programs easily.

Wait, you said "relevant information"... Respectfully, let me point that original context of the quote should show I was contrasting merely displaying information with organizing it into some degree of relevance.

> 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?

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?

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.

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?

> 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?

Because he wasn't so big a fan of Lisp Machines that he didn't get annoyed by their fanboys. He's relating this annecdote to demonstrate that he is not sijmply a die-hard Lisp Machine afficianado who can't let go.

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.

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?

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

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

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?

AFAIK RMS nixed it.

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

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!

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.

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

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

http://pastebin.com/m63016d1

This is Kent M Pitman replying to cba...@2xtreme.net (Christopher R. Barry)

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.

Reply on news.ycombinator.com