Live data from Hacker News

The lost cause of the Lisp machines

tfeb.org

121–130 of 176 posts

Re: The lost cause of the Lisp machines

#121

To me, it was never about the hardware. It was not even about LISP. It is about "clean design" and what a great computing environment was capable of, and still would be, had its potential not been shredded by the advent of cheap addicting hardware combined with an "operating system" so "simple and elegant" that even today, a program simply segfaults leaving you with nothing (instead of showing at least an inspectable…

I don’t want an Open Genera machine in a portable case with a battery, though. I want Apple’s software to match the quality of their hardware.

Re: The lost cause of the Lisp machines

#122

I'm not so sure it's down to the hardware. With something like 180-bit wide microcode store - a very very horizontal microarchitecture - the hardware sure was specialised, but I think it's fundamentally down to Lisp itself. I don't know a lot of Lisp. I did some at school as a teenager, on BBC Micros, and it was interesting, but I never did anything really serious with it. I do know about Forth though, so perhaps peo…

> Sadly, Forth, much as I love it and have done since I got my hands on a Jupiter Ace when I was about 9 or 10 years old, has not been a success, and probably for the same reasons as Lisp. I don't like when anything short of taking over the world counts as failure. Forth has been an enormous success! Forth has visited asteroids, run factories and booted millions of computers. It has done well, and if it's heading off…

I didn't say it was a failure, I just said it wasn't a success.

It fits a particular ecological niche, but these days there's almost no reason to do things that way. In the olden days of the early 90s when I needed to write embedded code to run on what was basically a Z80 SBC, it was easier to write a Forth for it and assemble it natively on a clunky old CP/M machine (I used a Kaypro of some sort at work, but an Osborne 1 at home) than it was to struggle on with the crappy (like, really crappy) MS-DOS cross-assembler on the PCs we had.

Now of course I could emulate every single computer in the entire company on a ten quid embedded board, all at the same time.

Re: The lost cause of the Lisp machines

#123
This just reminds me of the people who whine about Betamax (or CCS) being better.

FWIW: Technology Connections did a teardown of why Betamax wasn't better than VHS: https://www.youtube.com/watch?v=_oJs8-I9WtA&list=PLv0jwu7G_D...

And the whole series if you actually enjoy watching these things: https://www.youtube.com/playlist?list=PLv0jwu7G_DFUrcyMYAkUP...

Re: The lost cause of the Lisp machines

#124

>> ‘It was the development environment’ > No, it wasn’t. I kind of think it was . The best argument I think is embodied in Kent Pitman's comments in this usenet thread [1] where he argues that for the Lisp Machine romantics (at least the subset that include him) what they are really referring to is the total integration of the software , and he gives some pretty good examples of the benefits they bring. He freely adm…

You would like this dump too then:

https://www.yarchive.net/comp/lisp_support.html

Re: The lost cause of the Lisp machines

#125
post #34
post #19

As someone who used Franz LISP on Sun workstations while someone else nearby used a Symbolics 3600 refrigerator-sized machine, I was never all that impressed with the LISP machine. The performance wasn't all that great. Initially garbage collection took 45 minutes, as it tried to garbage-collect paged-out code. Eventually that was fixed. The hardware was not very good. Too much wire wrap and slow, arrogant maintenanc…

Lisp Machines had versioning file systems IIRC. Kinda like on VMS. Was SCCS really that far ahead?

Ummmm... yes. The problem with versioning file systems is that they only kept the last few versions; for files under active development, it was usually difficult to recover state older than a week or two.

(SCCS handled collaborative development and merges a lot worse than anything current, but... versioning file systems were worse there, too; one war story I heard involved an overenthusiastic developer "revising" someone else's file with enough new versions that by the time the original author came back to it, their last version of the code was unrecoverable.)

Re: The lost cause of the Lisp machines

#126
post #3

Symbolics’ big fumble was thinking their CPU was their special sauce for way too long. They showed signs that some people there understood that their development environment was it, but it obviously never fully got through to decision-makers: They had CLOE, a 386 PC deployment story in partnership with Gold Hill, but they’d have been far better served by acquiring Gold Hill and porting Genera to the 386 PC architectu…

Xerox/Venue tried porting Interlisp (the Lisp machine environment developed at Xerox PARC) to both Unix workstations and commodity PC hardware, but it doesn't seem like that was a commercial success. Venue remained a tiny company providing support to existing Interlisp customers until its head developer died in the late 2000s and they wrapped up operations. The Unix/PC ports seem to have mostly been used as a way to run legacy Interlisp software on newer hardware rather than attracting anyone new to the Lisp machine world. I don't see why Symbolics doing the same thing as Xerox would have produced any different results. The real problem was that investment in expert systems/Lisp dried up as a whole. I don't know whether any of the Lisp vendors could have done anything to combat those market forces.

Re: The lost cause of the Lisp machines

#127
post #3

Symbolics’ big fumble was thinking their CPU was their special sauce for way too long. They showed signs that some people there understood that their development environment was it, but it obviously never fully got through to decision-makers: They had CLOE, a 386 PC deployment story in partnership with Gold Hill, but they’d have been far better served by acquiring Gold Hill and porting Genera to the 386 PC architectu…

I think it would have been easier to port the MIT/LMI/TI environment to standard hardware as it was still 32-bit.

Re: The lost cause of the Lisp machines

#128

This just reminds me of the people who whine about Betamax (or CCS) being better. FWIW: Technology Connections did a teardown of why Betamax wasn't better than VHS: https://www.youtube.com/watch?v=_oJs8-I9WtA&list=PLv0jwu7G_D... And the whole series if you actually enjoy watching these things: https://www.youtube.com/playlist?list=PLv0jwu7G_DFUrcyMYAkUP...

I liked betamax better, sorry. The tapes were more compact and used less storage space. Can't argue with that. I also liked that you could use betamax with a Sony PCM F1 processor to record digital audio before the advent of the DAT format (digital audio tape). Can't argue with that. But when was the last time I even thought about betamax? Much more front of mind are the vagaries of blu-ray formats; and I rarely think about them either.

Re: The lost cause of the Lisp machines

#129
post #114

funny no mention about the texas instruments explorer: https://en.wikipedia.org/wiki/Texas_Instruments_Explorer i barely got to play with one for a few hours during an "ai" course, so i didn't really figure much of it out but ... oh yeah, it was "cool"! also way-way-way over my budget. i then kept an eye for a while on the atari transputer workstation but no luck, it never really took off. anyway, i find this article…

The author has owned Lisp Machines himself, maybe still does.

Re: The lost cause of the Lisp machines

#130

Lisp is alive as ever in Emacs and Common Lisp, and Clojure and Racket

And Tcl lives on in GDB, sure, just as M4 is forever alive with ubiquitous use of autotools.

Not quite the same thing. All the software I mentioned above have communities that constantly push to improve the ecosystem.
Post reply on HN