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

101–110 of 176 posts

Re: The lost cause of the Lisp machines

#101

Post by arethuza »

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…

I thought that was just me - I really rather liked Python the language but was completely confused at how the package system seemed to work.... Mind you this was 12 years ago or so but it was enough to put me off using it ever again.

Re: The lost cause of the Lisp machines

#102

Post by teunispeters »

dreamcompiler wrote: post #99
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.

"sort of". C++ is a lot more stable ABI these days, but linking still means looking into name mangling and data types. At least it no longer seems to be changing between compiler patches, as with - say - earlier GCC. (gcc 2 through 4 were not fun for this)

From a look a little, it seems rust has this pretty reliably - probably helped by sharing link environments with LLVM.

(I've only explored this a little from time to time). Mostly my work is all C and a bit of C++.

Re: The lost cause of the Lisp machines

#103

Post by rjsw »

mghackerlady wrote: post #6
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.

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

There were attempts to create a "Java Machine". Apart from JOP that is mentioned in another comment there were other systems that had a whole OS written in Java, a stub interrupt handler written in assembler would call into Java for any event.

Re: The lost cause of the Lisp machines

#105

Post by DonHopkins »

larsbrinkhoff wrote: post #17
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.

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

[dead]

Re: The lost cause of the Lisp machines

#106

Post by MangoToupe »

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…

> The hardware was not very good.

The hardware was never very interesting to me. It was the "lisp all the way down" that I found interesting, and the tight integration with editing-as-you-use. There's nothing preventing that from working on modern risc hardware (or intel, though please shoot me if I'm ever forced back onto it).

Re: The lost cause of the Lisp machines

#107

Post by iLemming »

raverbashing wrote: post #32
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…

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

There's 'FP stacks' and "FP stacks" and some aren't expressly similar. Volumes of money/data get handled by FP stacks - Jane Street famously uses OCaml; Cisco runs their entire cybersec backend on Clojure; Nubank covers entire Latin America and about to spread into the US - runs on Clojure on Elixir; Apple has their payment system, Walmart their billing, Netlfix their analytics on Clojure; Funding Circle in Europe and Splash in the US; etc. etc. There are tons of actual working products built on FP stacks. Just because your object-oriented brain can't pattern match the reality, it doesn't mean it's not happening.

Re: The lost cause of the Lisp machines

#108

Post by ux266478 »

DonHopkins wrote: post #57
jacquesm wrote: post #55

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?

thats a gen alpha thing sorry unc

Re: The lost cause of the Lisp machines

#109

Post by hajile »

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…

There seem to be very real differences between x86 and ARM not only in the designs they make easy, but also in the difficulty of making higher-performance designs.

It's telling that ARM, Apple, and Qualcomm have all shipped designs that are physically smaller, faster, and consume way less power vs AMD and Intel. Even ARM's medium cores have had higher IPC than same-generation x86 big cores since at least A78. SiFive's latest RISC-V cores are looking to match or exceed x86 IPC too. x86 is quickly becoming dead last which should be possible if ISA doesn't matter at all given AMD and Intel's budgets (AMD for example spends more in R&D than ARM's entire gross revenue).

ISA matters.

x86 is quite constrained by its decoders with Intel's 6 and 8-wide cores being massive and sucking an unbelievable amount of power and AMD choosing a hyper-complex 2x4 decoder implementation with a performance bottleneck in serial throughput. Meanwhile, we see 6-wide

32-bit ARM is a lot more simple than x86, but ARM claimed a massive 75% reduction in decoder size switching to 64-bit-only in A715 while increasing throughput. Things like uop cache aren't free. They take die area and power. Even worse, somebody has to spend a bunch of time designing and verifying these workarounds which balloons costs and increases time to market.

Another way the ISA matters is memory models. ARM uses barriers/fences which are only added where needed. x86 uses much tighter memory model that implies a lot of things the developers and compiler didn't actually need/want and that impact performance. The solution (not sure if x86 actually does this) is doing deep analysis of which implicit barriers can be provably ignored and speculating on the rest. Once again though, wiring in all these various proofs into the CPU is complicated and error-prone which slows things down while bloating circuitry, using extra die area/power, and sucking up time/money that could be spent in more meaningful ways.

While the theoretical performance mountain is the same, taking the stairs with ARM or RISC-V is going to be much easier/faster than trying to climb up the cliff faces.

Re: The lost cause of the Lisp machines

#110

Post by iLemming »

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…

> slowly get over the "must coexist with other software"

I dunno, as a Lisper I don't even have to think very hard - virtually any platform available to me, I can write almost anything in Lisp - for JVM and .Net - with Clojure; for Lua with Fennel; for Flutter with ClojureDart; Python - libpython-clj; C/C++ - Jade, CL, Carp and Jank; BEAM - Clojerl and LFE; Shell-scripting - babashka; For targeting js there are multiple options - clojurescript, nbb, squint.

Knowing some Lisp today is as practical as it gets. I really feel like a true polyglot coder - switching between different Lisps, even for drastically dissimilar platforms incurs virtually zero overhead while jumping even between JS and TS is always a headache.

Post reply on HN