Live data from Hacker News

The lost cause of the Lisp machines

tfeb.org

51–60 of 176 posts

Re: The lost cause of the Lisp machines

#51
post #3

Symbolics’ big fumble was thinking their CPU was their special sauce for way too long. They showed signs that some people there understood that their development environment was it, but it obviously never fully got through to decision-makers: They had CLOE, a 386 PC deployment story in partnership with Gold Hill, but they’d have been far better served by acquiring Gold Hill and porting Genera to the 386 PC architectu…

To be fair to Symbolics: a lot of companies back then thought their CPU was the secret sauce. Some still do...

Re: The lost cause of the Lisp machines

#52
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…

> "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

Wouldn't the whole system be the product then? There's tradeoffs, but that's just integration.

Re: The lost cause of the Lisp machines

#53
post #40

Earlier quoted context omitted.

Not the ones I've used. Haskell compiles to executables, F# compiles to the same bytecode that C# does and can be shipped the same way (including compiling to executables if you need to deploy to environments where you don't expect the .NET runtime to be already set up), Clojure compiles to .jar files and deploys just like other Java code, and so on. I'll grant that there are plenty of languages that seemed designed…

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.

In most FP languages it is simple to print to screen and get a random number.

Pure functions often exist in practice and are useful for preventing many bugs. Sure, they may not be suitable for some situations but they can prevent a lot of foot guns.

Here's a Haskell example with all of the above:

  import System.Random (randomRIO)

  main :: IO ()
  main = do
    num  Int
  pureFunction x = x * x + 2 * x + 1

Re: The lost cause of the Lisp machines

#54
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…

[flagged]

Re: The lost cause of the Lisp machines

#55

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]

This is such a hilarious comment.

Thank you for making my day.

Re: The lost cause of the Lisp machines

#56
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.

See also: Amiga romantics. 8-bit romantics. PDP-10 romantics. Let them stay. Let them romantizice.

You're using an 8-bit machine right now.

Re: The lost cause of the Lisp machines

#57

Earlier quoted context omitted.

[flagged]

This is such a hilarious comment. Thank you for making my day.

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?

Re: The lost cause of the Lisp machines

#58

Earlier quoted context omitted.

This is such a hilarious comment. Thank you for making my day.

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.

Re: The lost cause of the Lisp machines

#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 debate, like the LISP machine debate, really only lasted like 5 years. The fact is, we are all using out-of-order superscalar hardware where the decoder(s) of the CPU is not even close to the main thing consuming power and area on these chips. Under the hood they are all doing pretty much the same thing. But because it has a name and a marketable "war" and that people can easily understand the difference between fixed-width vs variable-width encodings, people overestimate the significance of the one part they understand compared to the internal engineering choices and process node choices that actually matter that people don't know about or understand. Unfortunately a lot of people hear the RISC vs CISC bedtime story and think there's no microcode on their M series chips.

You can go read about the real differences on sites like Chips and Cheese, but those aren't pop-sciencey and fun! It's mostly boring engineering details like the size of reorder buffers and the TSMC process node and it takes more than 5 minutes to learn. You can't just pick it up one day like a children's story with a clear conclusion and moral of the story. Just stop. If I can acquire all of your CPU microarchitecture knowledge from a Linus Tech tips video, you shouldn't have an opinion on it.

If you look at the finished product and you prefer the M series, that's great. But that doesn't mean you understand why it's different from the Zen series.

Re: The lost cause of the Lisp machines

#60
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.

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")

Azul Systems was making Java machines a while ago.
Post reply on HN