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

81–90 of 176 posts

Re: The lost cause of the Lisp machines

#81

Post by graemep »

whstl wrote: post #38
raverbashing wrote: post #32

Earlier quoted context omitted.

> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks

Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perh…

TCL has good solutions for this, but its not made it a success.

Where I see Python used is in places where you do not need it packaged as executables:

1. Linux - where the package manager solves the problem. I use multiple GUI apps written in python

2. On servers - e.g. Django web apps, where the the environment is set up per application

3. Code written for specific environments - even for specific hardware

4. One off installs - again, you have a specified target environment.

In none of the above cases do I find the environment to be fragile. On the other hand, if you are trying to distribute a Windows app to a large number of users I would expect it to be problematic.

Re: The lost cause of the Lisp machines

#82

Post by richardjdare »

karlgkk wrote: post #4

“ I am just really bored by Lisp Machine romantics at this point: they should go away. I expect they never will.” What? They’re awesome. They present a vision of the future that never happened. And I don’t think anyone serious expects lisp machines to come back btw.

For me what's inspiring about lisp machines is not any particular implementation detail, but the very idea that working with a computer can be this immersive, holistic experience where everything is accessible and workable through a single, but multidimensional human affordance; language. That the APIs and code within a computer system can be the ergonomic inward counterpart to rich accessible user interfaces, just as a man works with his hands and looks with his eyes, but easily turns inward to think and imagine. This is what I felt when I got that leaked Genera image going in a linux VM several years ago.

Its fair enough to say that lisp machines had this or that hardware limitation, or that they weren't really compatible with market needs, but to criticize 'lisp machine romantics' like this article does is to fail to understand what really motivates that romanticism. Maybe you have to be a romantic to really get it. Romanticism is abstract, its about chasing feelings and inspirations that you don't really understand yet. Its about unrealized promises more than its about the actual concrete thing that inspires them.

(I'm also an Amiga romantic, and I think what inspires me about that machine is equally abstract and equally points to a human attitude towards making and using software that seems sadly in decline today)

Re: The lost cause of the Lisp machines

#83

Post by Joker_vD »

ErroneousBosh wrote: post #68
Validark wrote: post #59

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!

But even ARM1 had some concessions to pragmatics, like push/pop many registers (with a pretty clever microcoded implementation!), shifted rigsters/rotated immediates as operands, and auto-incrementing/decrementing address registers for loads/stores.

Stephen Furber has extended discussion of the trade-offs involved in those decisions in his "VLSI RISC Architecture and Organization" (and also pretty much admits that having PC as a GPR is a bad idea: hardware is noticeably complicated for rather small gains on the software side).

Re: The lost cause of the Lisp machines

#85

Post by lycopodiopsida »

vindarel wrote: post #80
pjmlp wrote: post #9

The Lisp environments are definitely around, in LispWorks and Allegro Common Lisp.

And the Lem editor (an Emacs-like in Common Lisp).

Rather just "an Emacs" - it was a family of editors, after all, with GNU Emacs being the only one living offspring.

Re: The lost cause of the Lisp machines

#86

Post by whstl »

graemep wrote: post #81
whstl wrote: post #38

Earlier quoted context omitted.

Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perh…

TCL has good solutions for this, but its not made it a success. Where I see Python used is in places where you do not need it packaged as executables: 1. Linux - where the package manager solves the problem. I use multiple GUI apps written in python 2. On servers - e.g. Django web apps, where the the environment is set up per application 3. Code written for specific environments - even for specific hardware 4. One of…

You don't find the environment to be fragile because millions of human hours have been spent fixing those problems or working around them.

Which is significantly more than was needed for different technologies to achieve similar results.

Re: The lost cause of the Lisp machines

#87

Post by kryptiskt »

ErroneousBosh wrote: post #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 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 into the sunset it should be remembered for what it did rather than what it didn't do. I would be beyond thrilled if my language did a tenth as well as Forth.

Re: The lost cause of the Lisp machines

#88

Post by EdwardCoffin »

>> ‘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 admits there's not any reason why the experience could not be reproduced on other systems, it's that it hasn't been that is the problem.

I found his two specific examples particularly interesting. Search for

    * Tags Multiple Query Replace From Buffer
and

    * Source Compare
which are how he introduced them. He also describes "One of the most common ways to get a foothold in Genera for debugging" which I find pretty appealing, and still not available in any modern systems.

[1] https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/X...

Re: The lost cause of the Lisp machines

#89

Post by johnisgood »

varjag wrote: post #34
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…

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

You are correct, see: https://en.wikipedia.org/wiki/Versioning_file_system#LMFS.

Also: https://hanshuebner.github.io/lmman/pathnm.xml

It is worth mentioning that while it is not versioning per se, APFS and ZFS support instantaneous snapshots and clones as well.

Btrfs supports snapshots, too.

HAMMER2 in DragonFlyBSD has the ability to store revisions in the filesystem.

Re: The lost cause of the Lisp machines

#90

Post by lgrapenthin »

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 stacktrace). So "simple and elegant" that the only two data formats end users are dealing with are "copy & paste text", "files", and "screenshots". An operating system so "pure" that every program lives in its own uninteroperable walled garden, that understands nothing about the environment and data loaded around it. We lost a whole computing world and it might still take ages getting that back.
Post reply on HN