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

171–176 of 176 posts

Re: The lost cause of the Lisp machines

#171

Post by paulddraper »

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…

You don't believe that Intel chips have more instructions and complexity and AMD have fewer?

Neither is "simple" but the axis is similar.

Re: The lost cause of the Lisp machines

#172

Post by salutis »

iLemming wrote: post #111
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.

For me, Emacs on Mac OS is not all that stable. I see a freeze about twice a month, which is not "very rarely" in my book. It also leaks memory, albeit now (in the upcoming version) less so. (Disclaimer: I am a heavy user and contributor.)

Re: The lost cause of the Lisp machines

#173

Post by iLemming »

salutis wrote: post #172
iLemming wrote: post #111

Earlier quoted context omitted.

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

For me, Emacs on Mac OS is not all that stable. I see a freeze about twice a month, which is not "very rarely" in my book. It also leaks memory, albeit now (in the upcoming version) less so. (Disclaimer: I am a heavy user and contributor.)

What version of Emacs are you using? I stopped using Mitsuharu port because of its weird behaviors and instability and been using plain GNU/Emacs - typically I install it via emacs-plus homebrew formula. It's been very stable for me for the past few years.

Re: The lost cause of the Lisp machines

#174

Post by dtagames »

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…

You've hit the nail on the head. It's the inability to ship product from a Lisp machine that killed the idea. The fungibility of Lisp all the way down turned each machine into a one-off lab of its own. And this tech arrived after the industry had started moving from bespoke solutions provided by hardware companies to packaged software from specialized firms. Since Lisp machines aren't good at maintaining a duplicatable environment, they're not terribly useful for commercial software production nor as a distribution target.

Source: I was a mainframe compiler developer at IBM during this era.

Re: The lost cause of the Lisp machines

#175

Post by eschaton »

rjsw wrote: post #127
eschaton wrote: 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…

I think it would have been easier to port the MIT/LMI/TI environment to standard hardware as it was still 32-bit.

There’s not a huge amount of _explicit_ dependency on the bit width of the system in either the 3600 or Ivory. Of course there’s still plenty of _implicit_ dependency in terms of hardware interaction, object layout in memory, collector implementation, etc. but that’s all stuff that had to be dealt with anyway to port from CADR to 3600 in the first place, and then again to port from 3600-series to Ivory.

Re: The lost cause of the Lisp machines

#176

Post by rjsw »

eschaton wrote: post #175
rjsw wrote: post #127

Earlier quoted context omitted.

I think it would have been easier to port the MIT/LMI/TI environment to standard hardware as it was still 32-bit.

There’s not a huge amount of _explicit_ dependency on the bit width of the system in either the 3600 or Ivory. Of course there’s still plenty of _implicit_ dependency in terms of hardware interaction, object layout in memory, collector implementation, etc. but that’s all stuff that had to be dealt with anyway to port from CADR to 3600 in the first place, and then again to port from 3600-series to Ivory.

I was thinking that someone could have rewritten the CADR microcode to run on a 68020+Custom MMU system with no other OS, there isn't all that much of it.

This would be tied to the bit width of the system.

Post reply on HN