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

91–100 of 176 posts

Re: The lost cause of the Lisp machines

#91

Post by foobarian »

jacquesm wrote: post #47
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…

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…

You and me both. These days I don't even try, just docker pull python and docker run -v .:/app python /app/foo.py

Re: The lost cause of the Lisp machines

#92

Post by mghackerlady »

dehrmann wrote: post #28
mghackerlady wrote: post #6

Earlier quoted context omitted.

I'm honestly surprised nobody tried to capitalize on the early 2000s Java hype by making some kind of Java box (there were a few things labeled as a Java OS or a Java workstation but none of these were really a "Java Machine")

Coincidentally on the front page, https://news.ycombinator.com/item?id=45989650 ARM also used to have opcodes for Java: https://en.wikipedia.org/wiki/Jazelle

Haha, I was the one who submitted it after going down a rabbit hole from this :)

Re: The lost cause of the Lisp machines

#93

Post by dieortin »

lgrapenthin wrote: post #90

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…

If you ship debug symbols with your binary, you do get a core dump with an inspectable stacktrace…

Re: The lost cause of the Lisp machines

#94

Post by teunispeters »

Lisp - historically - did not work well with others. Did not share spaces, did not coexist with other systems particularly well. Or if it did, it would wrap them very carefully in "unsafe" and keep as much to the boundaries as possible.

It's not like it's the only system that suffers this, but "working well with others" is a big key to success in almost every field.

I'm absolutely fascinated by what worked and was possible in that venue, just like I find rust code fascinating. These days lisp is much more workable, as they slowly get over the "must coexist with other software". There are still things that are really hard to put in other computer languages.

Re: The lost cause of the Lisp machines

#95

Post by rjsw »

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.

Re: The lost cause of the Lisp machines

#96

Post by mr_toad »

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…

But people start by hacking away with one-off installs written for their specific environments, get it to the point where it’s useful to others, and then expect others to install all the tools and dependencies needed to install it.

Quick start guide: works on my machine.

Re: The lost cause of the Lisp machines

#97

Post by dreamcompiler »

raverbashing wrote: post #74
jacquesm wrote: post #49

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 I agree, pure functions are good building blocks (for the most part), but I don't think the current abstractions and ways of bridging the FP and Procedural world are good enough Also have you managed to eliminate the side effect of your IP register changing when your program is running? ;)

I love FP but at the end of the day registers are global variables. Half of modern compiler theory consists of workarounds for this sad truth.

Re: The lost cause of the Lisp machines

#98

Post by mr_toad »

raverbashing wrote: post #74
jacquesm wrote: post #49

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 I agree, pure functions are good building blocks (for the most part), but I don't think the current abstractions and ways of bridging the FP and Procedural world are good enough Also have you managed to eliminate the side effect of your IP register changing when your program is running? ;)

> but I don't think the current abstractions and ways of bridging the FP and Procedural world are good enough

I find that both Python and Javascript allow you to use functional code when appropriate, without forcing you to use it when it isn’t.

Re: The lost cause of the Lisp machines

#99

Post by dreamcompiler »

teunispeters wrote: post #94

Lisp - historically - did not work well with others. Did not share spaces, did not coexist with other systems particularly well. Or if it did, it would wrap them very carefully in "unsafe" and keep as much to the boundaries as possible. It's not like it's the only system that suffers this, but "working well with others" is a big key to success in almost every field. I'm absolutely fascinated by what worked and was po…

These days Lisp works pretty well with C because C has a defined ABI. That was historically not the case for C++, so to call C++ functions you needed to first wrap them in C.

C++ might be easier now; I don't know.

Re: The lost cause of the Lisp machines

#100

Post by AnimalMuppet »

ErroneousBosh wrote: post #61
rmunn wrote: post #39

Earlier quoted context omitted.

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…

All true, but all the ones you list were very small bubbles. The dotcom bubble is the only one comparable (in size and industry-wide enthusiasm) to the LLM bubble.
Post reply on HN