Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The lost cause of the Lisp machines

tfeb.org

Post reply on HN
Print view View original

111–120 of 176 posts

Re: The lost cause of the Lisp machines

#111

Post by iLemming »

logicprog wrote: post #48

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.

> I just want a more stable

Emacs is incredibly stable. Most problems happen in custom-made packages. I don't even remember Emacs ever segfaulting for me on Linux. On Mac it can happen, but very rarely. I don't ever remember losing my data in Emacs - even when I deliberately kill the process, it recovers the unsaved changes.

Re: The lost cause of the Lisp machines

#112

Post by Peteragain »

mietek wrote: post #71
Peteragain wrote: post #29

Okay they're dead, but I think the interesting thing here is the relationship between hardware and the way mathematicians (potentially) think about problem solving. The established practices massively constrain the solutions we find, but I do wonder what a Turing Machine would look like if FPGAs had been around in 1930. FPGAs keep getting used to implement processors, but using one to make a c interpreter and then us…

Some things have been tried; some things continue to be tried. - Naylor and Runciman (2007) ”The Reduceron: Widening the von Neumann Bottleneck for Graph Reduction using an FPGA”: https://mn416.github.io/reduceron-project/reduceron.pdf - Burrows (2009) “A combinator processor”: https://q4.github.io/dissertations/eb379.pdf - Ramsay and Stewart (2023) “Heron: Modern Hardware Graph Reduction”: https://dl.acm.org/doi/10.…

Wow! Thanks! It was a half a thought but that interaction is right up there with "the big red button" and makes the last 20 years of enshitification all worth while!

Re: The lost cause of the Lisp machines

#114

Post by znort_ »

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 quite out of place. what hordes of romantically spoiled lisp machine nostalgia fanatics harassed this poor guy to the extreme that he had to go on this (pretty pointless) disparaging spree?

Re: The lost cause of the Lisp machines

#115

Post by e40 »

Animats wrote: 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…

I worked on Franz Lisp at UCB. A couple of points:

The ".obj" file was a binary file that contain machine instructions and data. It was "fast loaded" and the file format was called "fasl" and it worked well.

The issue of building an application wasn't an issue because we had "dumplisp" which took the image in memory and wrote it to disk. The resulting image could be executed to create a new instance of the program, at the time dumplisp was run. Emacs called this "unexec" and it did approximately the same thing.

Maybe your discussions with my group predated me and predated some of the above features, I don't know. I was Fateman's group from '81-84.

I assume your source control comments were about the Lisp Machine and not Franz Lisp. RCS and SCCS were a thing in the early 80's, but they didn't really gain steam until after I arrived at UCB. I was the one (I think... it was a long time ago) that put Franz Lisp under RCS control.

Re: The lost cause of the Lisp machines

#116

Post by e40 »

rjsw wrote: post #95
Animats wrote: 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…

Franz Lisp could create standalone executables from very early in the project, the compiler is one.

Correct. To continue the puns, it was called Liszt.

Re: The lost cause of the Lisp machines

#117

Post by iLemming »

arethuza wrote: post #101
jacquesm wrote: post #47

Earlier quoted context omitted.

Don't get me started. I tried to use a very simply python program the other day, to talk to a bluetooth module in a device I'm building. In the end I gave up and wrote the whole thing in another language, but that wasn't before fighting the python package system for a couple of hours thinking the solution is right around the corner, if only I can get rid of one more little conflict. Python is funny that way, it infan…

I thought that was just me - I really rather liked Python the language but was completely confused at how the package system seemed to work.... Mind you this was 12 years ago or so but it was enough to put me off using it ever again.

Yeah, it's still shitty. So often I have to go through some weird hoops to even just run the tests for a project with commits made last week. I can't even ask Claude to explain something about any given repo, it naively tries to run them tests, only to hit the wall. The number of different linters and checkers we have to run on CI just to make sure things are in good state, yet every time I clone something and try to get it running, almost always some kind of bullcrap. Why the fuck we even keep trying to write things in Python, I just don't get it.

Re: The lost cause of the Lisp machines

#118

Post by iLemming »

ErroneousBosh wrote: post #54
jacquesm wrote: post #47

Earlier quoted context omitted.

Don't get me started. I tried to use a very simply python program the other day, to talk to a bluetooth module in a device I'm building. In the end I gave up and wrote the whole thing in another language, but that wasn't before fighting the python package system for a couple of hours thinking the solution is right around the corner, if only I can get rid of one more little conflict. Python is funny that way, it infan…

[flagged]

> you're not very good at computers.

Yup, I guess I am not. Been coding for over 20 years, went through over a dozen different PLs and only Python - the best fucking friend who doesn't sugar coat it, tells you without stuttering - "you suck at this, buddy"

     # PEP 9001: Constructive Computing Feedback

     ## Abstract

     This PEP proposes a standardized error message for situations where Python interpreters shall inform the user of insufficient computational competence.

     ## Specification

     When a user attempts to execute Python code that supposedly should work but it doesn't, the interpreter shall emit:

         You're suck at computers

Re: The lost cause of the Lisp machines

#120

Post by PaulHoule »

This document

https://userpages.umbc.edu/%7Evijay/mashey.on.risc.html

explains a lot of "what happened in the 1980s?" particularly why VAX and 68k were abandoned by their manufacturers. The last table shows how processors that had really baroque addressing modes, particularly involving indirection, did not survive. The old 360 architecture was by no means RISC but it had simple addressing modes and that helped it survive.

A Lisp-optimized processor would be likely to have indirection and generally complex ways how instructions can fail which gets in the way of efficient pipelined implementations. People like to talk about "separation of specification and implementation" but Common Lisp was designed with one eye on the problem of running it efficiently on the "32-bit" architectures of the 1980s and did OK on the 68k which was big then and also with the various RISC architectures and x86 which is simple enough that it is practical to rewrite the instruction stream into microinstructions which can be easily executed.

Post reply on HN