Live data from Hacker News

Why we need Lisp machines

fultonsramblings.substack.com

31–40 of 220 posts

Re: Why we need Lisp machines

#31
post #23

If were talking about wild dreams, I would like to see a modern Plan9-like operating system written in lisp. While the Plan9 mouse chording is cool (and could be kept), I would have everything also accessible via keyboard commands. 3 button mouse chording on a laptop trackpad is not fun.

Executable-images-and-bytestreams (Research Unix, Plan 9) and everything-is-in-$LANGUAGE (Lisp machines, Emacs, Smalltalk, Oberon, Forth) environments seem largely contradictory to me, because much of the flexibility in Unix seems to come from the freedom to ignore as much structure in the data as you want to, while programming-language environments seem to derive their advantages from expressing the structure in as detailed a way as possible. (In particular, they really want to invent their own storage formats for everything.) I don’t have much of an idea about Inferno, but my superficial impression is it also mostly ends up as a single-language island.

Which is annoying, because both of these approaches produce some really attractive results, so I’d very much like to learn about any attempts to reconcile them.

Re: Why we need Lisp machines

#32
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: Why we need Lisp machines

#33

So it's interesting to note modern hardware is only 60x faster than Lisp machines when it should be 1000x. Weirdness of Lisp, turns out hardware isn't some random thing. And harder to compromise than modern stuff, by a huge amount, real actual security improvement.

Not saying you're wrong, but do you have a source for the 60/1000x number? Curious to read more.

Re: Why we need Lisp machines

#34

Earlier quoted context omitted.

>> UNIX isn’t good enough anymore and it’s getting worse >Why exactly? Personally? We're in a bit of a transition point, and a lot of the technologies aren't working together like they used to. An example, on my laptop I want to run android apps. The way to do this that actually works well (waydroid) only supports wayland. Unfortunately I use x2x to control another display remotely, and x2x doesn't work properly unde…

I am finding that everything is just becoming more and more fragmented. Programming languages, ecosystems, frameworks, blah. I have had ideas for some applications, but can’t do them because the libraries I need are written in different languages, which don’t interoperate well (and one I am not familiar in). Every post here looking for recommendations has many responses with different packages/ecosystems doing the sa…

It isn't nice? Back to the 8 and 16 bit home computers, when we had plenty of choice and real fights on the school playground about which were better.

Re: Why we need Lisp machines

#35

Earlier quoted context omitted.

>> UNIX isn’t good enough anymore and it’s getting worse >Why exactly? Personally? We're in a bit of a transition point, and a lot of the technologies aren't working together like they used to. An example, on my laptop I want to run android apps. The way to do this that actually works well (waydroid) only supports wayland. Unfortunately I use x2x to control another display remotely, and x2x doesn't work properly unde…

I am finding that everything is just becoming more and more fragmented. Programming languages, ecosystems, frameworks, blah. I have had ideas for some applications, but can’t do them because the libraries I need are written in different languages, which don’t interoperate well (and one I am not familiar in). Every post here looking for recommendations has many responses with different packages/ecosystems doing the sa…

I think they are too invested im hard problems, but not invested enough in tedious problems.

I don't want a new language, or a new preprocesser, or a new way of thinking about programs... I just want a one click way to take a folder of HTML that looks like a static site, and package it up into cross platform apps with all the proper API access.

I don't care about cryptocurrency and global decentralized databases, I just want to be able to run a site by buying a NAS appliances, putting files on it, and sharing the QR code on it without any signups and cloud accounts.

The hard problems are mostly solved. There's probably some long dead random github repo that does anything you want. They're just not packaged for all platforms and maintained professionally.

I don't need a phone without any binary blobs at all... I just want a mesh network feature and a fair trade stamp.

Because... it sucks to maintain something novel even if it's all just pieced together from npm. It sucks to be the one responding to issues. It sucks to actually run a project and keep track of devops stuff.

All the tech has been invented dozens of times over, but never polished, and always ruined with some unnecessary immutable log feature or performance destroying random access low latency routing thing like IPFS has.

Re: Why we need Lisp machines

#36

Earlier quoted context omitted.

So a perfect use-case for the obligatory XKCD post about "too many standards, invent one more to try to solve the issue => too many standards plus one".

I don't think standards are the problem. I think a wave of new standards causes issues like the above, and eventually this gets worked out. Not all "standards" in practice become standard. We learn a lot of "standards" were bad ideas, and they eventually get tossed out and most people forget anyone was ever trying to make that a thing.

"Standards" in this case just means "things that I/we developed that we think should be adopted by lots of other people because it's awesome-sauce"

Re: Why we need Lisp machines

#37
post #23

If were talking about wild dreams, I would like to see a modern Plan9-like operating system written in lisp. While the Plan9 mouse chording is cool (and could be kept), I would have everything also accessible via keyboard commands. 3 button mouse chording on a laptop trackpad is not fun.

It used Limbo and was called Inferno.

Re: Why we need Lisp machines

#38
post #6

For a somewhat complete history of LISP machines, I recommend reading "Hackers: Heroes of the Computer Revolution" [1]. [1] https://www.goodreads.com/book/show/8260364-hackers

Thanks for the recommendation.

I've been learning/using CL, on the side, for about a year, in fits and starts, and I'm also picking up a lot of it's history and evolution along the way.

I find the history of the thing is as fascinating as the language/tools.

There's so much written on this but it's hard to aggregate and put together. Links lead to other links that lead to other links and oftentimes a lot of them are dead.

So I'm glad that there are books like this that can preserve some pieces of the story.

Re: Why we need Lisp machines

#39
post #5

Some of this needs checking -- you could not run Unix on Symbolics hardware. LMI did have machines that ran both OSes -- but Unix was running on a separate 68000 processor; see, e.g. http://www.bitsavers.org/pdf/lmi/LMI_lambdaOverview_1982.pdf (3600-series Symbolics machines also had a 68k "front end processor", but no Unix port was provided for it; they also ultimately had a C compiler that could generate code for t…

What one could do was running hardware Lisp Machines from Symbolics on VME boards inside a SUN: the UX400 and UX1200.

Later Open Genera was sold as a Virtual Lisp Machine running on a DEC Alpha / UNIX system.

Re: Why we need Lisp machines

#40
post #26

When the author talks about too many languages and libraries, I personally think he means the proliferation of Unix DSLs (some of which are Posix and some are not) like Make, Awk, Sed, BC, DC, shell-script dialects, Gnuplot (I know it's not Posix but it was widely used once), xargs, Vimscript, ELisp. Each of these has its own quirks and random limitations. Each of these makes Unix unnecessarily complicated and diffic…

I wouldn't even say any of those make UNIX difficult to learn. 99% of people can be users and developers just fine without learning awk or sed or even make, if they don't do low level work.

It can all be incrementally replaced over time, without starting over, just like how systemd and pipewire didn't need to totally start over.

Make will probably need something more than just a library though, because it's gotta stay declarative. But the fact that make exists at all is kind of an issue. I think build and package management should be done in the language itself like non-C languages do.

The other use of make is almost as a pseudo UI, just a standard place to put a list of actions you can do.

Something like Ansible could replace that, in theory, or we could have some new "project control center" file with menus and inputs and settings.

Post reply on HN