Hacker News Reader

Comment by ngcc_hk | Hacker News Reader

“ We’re not living in a world of Lisp machines, but a world of glorified PDP-11s.” Quite a summary.

Btw any icing with sdl I wonder.

Except conventional CPUs aren't really glorified PDP-11s, except in the sense that they're Von Neumann machines with untagged memory; and the conventional CPUs started lapping the Lisp machines around the mid-80s, when 32-bit microprocessors started becoming common and Lisp compiler technology evolved to better support them.

And even the "untagged memory" bit might not hold; with things like CHERI, a LispM style architecture is due for a major comeback.

Hi I think is in the hypothesis (I'm not sure) of that we have edition made by the pdp 11 keyboard developer and tooling that's old and design whiout introspection in mind showcase in this video, the video is really cool but little bit long

https://youtu.be/8Ab3ArE8W3s?si=FdwCbmRnU1gJIXJx

Or SPARC ADI and ARM MTE, already around, only Intel and AMD keep failing to deliver something that actually works, e.g. iAPX 432 and MPX.

Well.... I really liked the pdp-11; for years I had a pdp-11/45 in my living room, but eventually sold it to downsize to a couple of H-11 LSI-11/2 machines with dual 8" floppies.

Why? Well, the pdp-11, besides being the unix protoplasm, is conceptually well-designed. In the same way we tend to write routines that 'fit on a screen', the pdp-11's small directly addressable space encourages not-very-big modules: it encourages modularity.

Is it inadequate for today? Sure. Especially painful for Big Data. But, conceptually -- there's a reason the pdp-11 was so successful, and continues to exist vestigially.

Ironically we are now getting C Machines with hardware memory tagging, as there is no other way to fix C, and too much code around that will never be rewriten.

The ending is even better:

> "Rewrite it in Rust? No way! Rewrite it in Lisp!“

Lisp is unsuitable for modern CPUs because of memory hierarchy. Lisp operates primarily with lists, which can have pointers all over memory. This was not a problem on earlier CPUs because all memory was the same with similar random access time. Modern CPUs cannot access pointers in memory with the same speed, they need to follow locality rules for performance. This means that an algorithm using something like C or Fortran arrays will always be faster than a Lisp list based version.

Luckily, lisp has arrays too, and a bunch of other data structures besides lists.

Common Lisp allows one to use arrays or other structures, and can even be used to inline assembly. So despite lists being a major part of the ecosystem and code representation itself, they are not mandatory for implementing an algorithm, or necessarily a performance drawback to using lisp. By the same token, it's easy for people to accidentally use lists and pointers to implement algorithms just as inefficiently in other languages - Python comes to mind. A standard approach in Python is to lean on external libraries for high performance computation, and this can be done just the same way in Lisp - but Lisp can also be used directly to write efficient low level algorithms by making a conscious effort not to use the list- and pointer-based functions to do so.

If the cons cells are allocated linearly it's fine. Plus the fact that lisps have more data structures than just lists.

Depending on the implementation for short list they can be optimized (just as strings in C++). You may be right with C and Fortran. But tbh in an era where the tiniest thing has an OS with MMU, I really prefer GC when the performance is not a problem. If it is just a performance concern, then ASM will always beat C… Like everything in engineering is about the right trade off.

Modern CPUs can execute Lisp just fine, like they execute languages like Java and Javascript, which also use a lot of pointers. Just like those, Lisp offers vectors, strings, hash tables, structures/records and objects.

> This was not a problem on earlier CPUs because all memory was the same with similar access time.

That's not true. Many early systems had small RAM sizes (example: a DEC VAX 11/780 had a few Megabytes and often served dozens of users) and 10 (or more) times larger slow virtual memory.

Lisp systems then tried to deal with that with the first generational garbage collectors, often also compacting (related objects stayed near in memory). Ephemeral GCs watched for changed memory in RAM.

Please try one of the big Lisp/Scheme yourself instead of spreading uninformed opinions.

Apparently some people keep being stuck in 1960, when Lisp 1.5 manual was published.

Since the 1980's that modern Lisps support all common data structures.

Reply on news.ycombinator.com