Live data from Hacker News

The lost cause of the Lisp machines

tfeb.org

61–70 of 176 posts

Re: The lost cause of the Lisp machines

#61
post #39

> I’d be saying that in a few years there are going to be a lot of huge farms of GPUs going very cheap if you can afford the power. People could be looking at whether those can be used for anything more interesting than the huge neural networks they were designed for. Author falls into the same trap he talks about in the article. AI is not going away, we are not going back to the pre-AI world.

AI will not go away, I agree. But many of the companies now betting the farm on AI are going to lose, and there will be server farms going for sale cheap. I'm hearing more and more people outside the tech world talk about the AI bubble, and predicting it's going to pop. When that happens and investors lose confidence, suddenly companies who need the next round of financing to pay off their current debts won't get it,…

> I'm hearing more and more people outside the tech world talk about the AI bubble, and predicting it's going to pop

I'm juuust about old enough to remember the end of the Lisp Machine bubble (we had one or two at uni in the early 90s, and they were archaic by then). But obviously Lisp machines were the wrong way to go, even if they were a necessary step - obviously, hardware-mediated permanent object storage is the way forwards! POP! Ah, maybe not. Okay but can't you see we need to run all this on a massive transputer plane? POP! Oh. Okay how about this, we actually treat the microcode as the machine language, so the user-facing opcodes are like 256 bits long, and then we translate other instruction sets into that on the fly, like this - the Transmeta Crusoe! It's going to revolutionise everything! POP! Ah, what? Okay well how about...

And we're only up to the early 2000s.

It's bubbles, all the way back. Many of these things were indeed necessary steps - if only so We Learned Not To Do That Again - but ultimately are a footnote in history.

In 30 years' time people will have blog posts about how in the mid-2020s people had this thing where they used huge sheds full of graphics cards to run not-working-properly Boolean algebra to generate page after page after page of pictures of wonky-looking dogs and Santa Clauses, and we'll look at that with the same bemused nostalgia as we do with the line printer Snoopy calendars today.

Re: The lost cause of the Lisp machines

#62

Earlier quoted context omitted.

Hey Gen Z, as long as I have you on the line, could you please explain 67 to me? I've heard of "68 and I'll owe you one", so is 67 about owing you two?

I'm having a hard time coping with my social media addiction while doing some fairly hardcore development on an STM32 based platform so sorry :) Incidentally, when will you (multiple) come and visit? It's been too long.

I owe you at least one or two! Maybe we can test your drones out on that Russian guy with the GoFundMe campaign, then I'll owe you three! ;)

Re: The lost cause of the Lisp machines

#64

I'm a lisp machine romantic, but only for the software side. The hardware was neat, but nowadays I just want a more stable, graphically capable emacs that extends down through and out across more of userspace.

> emacs that extends down through and out across more of userspace

Making something like that has turned into a lifetime project for me. Implemented a freestanding lisp on top of Linux's stable system call interface. It's gotten to the point it has delimited continuations.

Re: The lost cause of the Lisp machines

#65

Earlier quoted context omitted.

True but some still wants me to understand what a monofunctor is or something that sounds like a disease to do things like print to screen or get a random number I feel that is the biggest barrier to their adoption nowadays (and also silly things like requiring ;; at the end of the line) Pure functions are a good theoretical exercise but they can't exist in practice.

> Pure functions are a good theoretical exercise but they can't exist in practice. Well, they can. But not all the way up to the top level of your program. But the longer you can hold off from your functions having side effects the more predictable and stable your codebase will be, with as an added benefit fewer bugs and less chance of runtime issues.

Yes, but they're "Hello world!" hostile, so traditional programming language pedagogy doesn't work well.

Q: How many Prolog programmers does it take to change a lightbulb?

A: Yes.

Re: The lost cause of the Lisp machines

#66
post #5

Time to dig up a classic story about Tom Knight, who designed the first prototype of the Lisp Machine at MIT in the mid-70's. It's in the form of a classic Zen koan. This copy comes from https://jargondb.org/some_ai_koans but I've seen plenty of variations floating around. A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: “You c…

That's one of the funniest and most enlightening classic AI Koans, originally from the ITS file "AI:HUMOR;AI KOANS".

Here's another Moon story from the humor directory:

https://github.com/PDP-10/its/blob/master/doc/humor/moon's.g...

Moon's I.T.S. CRASH PROCEDURE document from his home directory, which goes into much more detail than just turning it off and on:

https://github.com/PDP-10/its/blob/master/doc/moon/klproc.11

And some cool Emacs lore:

https://github.com/PDP-10/its/blob/master/doc/eak/emacs.lore

Reposting this from the 2014 HN discussion of "Ergonomics of the Symbolics Lisp Machine":

https://news.ycombinator.com/item?id=7878679

http://lispm.de/symbolics-lisp-machine-ergonomics

https://news.ycombinator.com/item?id=7879364

eudox on June 11, 2014

Related: A huge collections of images showing Symbolics UI and the software written for it:

http://lispm.de/symbolics-ui-examples/symbolics-ui-examples

agumonkey on June 11, 2014

Nice, but I wouldn't confuse static images with the underlying semantic graph of live objects that's not visible in pictures.

DonHopkins on June 14, 2014

Precisely! When Lisp Machine programmer look at a screen dump, they see a lot more going on behind the scenes than meets the eye.

I'll attempt to explain the deep implications of what the article said about "Everything on the screen is an object, mouse-sensitive and reusable":

There's a legendary story about Gyro hacking away on a Lisp Machine, when he accidentally trashed the function cell of an important primitive like AREF (or something like that -- I can't remember the details -- do you, Scott? Or does Devon just make this stuff up? ;), and that totally crashed the operating system.

It dumped him into a "cold load stream" where he could poke around at the memory image, so he clamored around the display list, a graph of live objects (currently in suspended animation) behind the windows on the screen, and found an instance where the original value of the function pointer had been printed out in hex (which of course was a numeric object that let you click up a menu to change its presentation, etc).

He grabbed the value of the function pointer out of that numeric object, poked it back into the function cell where it belonged, pressed the "Please proceed, Governor" button, and was immediately back up and running where he left off before the crash, like nothing had ever happened!

Here's another example of someone pulling themselves back up by their bootstraps without actually cold rebooting, thanks to the real time help of the networked Lisp Machine user community:

ftp://ftp.ai.sri.com/pub/mailing-lists/slug/900531/msg00339.html

Also eudox posted this link:

Related: A huge collections of images showing Symbolics UI and the software written for it:

http://lispm.de/symbolics-ui-examples/symbolics-ui-examples....

Re: The lost cause of the Lisp machines

#67
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 people with a sense of how both work can correct me here.

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.

It just looks plain weird.

It does. I mean I love how elegant Forth is, you can implement a basic inner interpreter and a few primitives in a couple of hundred lines of assembler and then the rest is just written in Forth in terms of those primitives (okay pages and pages of dw ADDRESS_OF_PRIMITIVE instructions rather Forth proper). I'm told that you can do the same trick with Lisp, and maybe I'll look into that soon.

But the code itself looks weird.

Every language that's currently successful looks like ALGOL.

At uni, I learned Turbo Pascal. That have way to Modula-2 in "real" programming but by then I'd gotten my hands on an account on the Sun boxes and was writing stuff in C. C looked kind of like Pascal once you got round the idea that curly brackets weren't comments any more, so it wasn't a hard transition. I wrote lots of C, masses and masses, and eventually shifted to writing stuff in Python for doing webby stuff and C for DSP. Python... looks kind of like ALGOL, actually, you don't use "begin" and "end", you just indent properly, which you should be doing. Then Go, much later, which looks kind of like Pascal to me, which in turn looks kind of like ALGOL.

And so on.

You write line after line after line of "this thing does this to that", and it works. It's like writing out a recipe, even more so if you declare your ingredients^W variables at the top.

I love Forth, I really want to love Lisp but I don't know enough about it, but everyone uses languages that look like ALGOL.

In the late 1960s Citroën developed a car where the steering and speed were controlled by a single joystick mounted roughly where the steering wheel would be. No throttle, no clutch, no gears, just a joystick with force feedback to increase the amount of force needed to steer as the car sped up. Very comfortable, very natural, even more so when the joystick was mounted in the centre console like in some aircraft. Buuuuut, everyone uses steering wheels and pedals. It was too weird for people.

Re: The lost cause of the Lisp machines

#68

I liked the article, but I found the random remark about RISC vs CISC to be very similar to what the author is complaining about. The difference between the Apple M series and AMD's Zen series is NOT a RISC vs CISC issue. In fact, many would argue it's fair to say that ARM is not RISC and x86-64 is not CISC. These terms were used to refer to machines vastly different from what we have today, and the RISC vs CISC deba…

> In fact, many would argue it's fair to say that ARM is not RISC

It isn't now... ;-)

It's interesting to look at how close old ARM2/ARM3 code was to 6502 machine code. It's not totally unfair to think of the original ARM chip as a 32-bit 6502 with scads of registers.

And, for fairly obvious reasons!

Re: The lost cause of the Lisp machines

#69
post #39

> I’d be saying that in a few years there are going to be a lot of huge farms of GPUs going very cheap if you can afford the power. People could be looking at whether those can be used for anything more interesting than the huge neural networks they were designed for. Author falls into the same trap he talks about in the article. AI is not going away, we are not going back to the pre-AI world.

AI will not go away, I agree. But many of the companies now betting the farm on AI are going to lose, and there will be server farms going for sale cheap. I'm hearing more and more people outside the tech world talk about the AI bubble, and predicting it's going to pop. When that happens and investors lose confidence, suddenly companies who need the next round of financing to pay off their current debts won't get it,…

> I'm hearing more and more people outside the tech world talk about the AI bubble, and predicting it's going to pop

You know what they say about when the taxi driver is giving you strong financial opinions.

Re: The lost cause of the Lisp machines

#70

Earlier quoted context omitted.

> Pure functions are a good theoretical exercise but they can't exist in practice. Well, they can. But not all the way up to the top level of your program. But the longer you can hold off from your functions having side effects the more predictable and stable your codebase will be, with as an added benefit fewer bugs and less chance of runtime issues.

Yes, but they're "Hello world!" hostile, so traditional programming language pedagogy doesn't work well. Q: How many Prolog programmers does it take to change a lightbulb? A: Yes.

I imagine LLMs have already thrown traditional programming language pedagogy out the window.
Post reply on HN