The glory days were not that glorious. There are stories out there of runaway garbage collections, that grinded on for days. Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built.
Data structures are dictated by the requirements of what you're doing, not the machine. Linked lists are out? The C middleware that runs everything is full of "struct foo { struct foo * next; int other_field ... }".
Linked lists benefit from caching, like other kinds of data.
> Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built.
The garbage collection in your web browser is complete, utter garbage compared to what Lisp people were doing 30-40 years ago. Sorry!
(I will add to this comment later; I have to go to Task Manager and kill the web browser.)
Can you back that statement up? GC has advanced heavily over the years (and still is).The first paper on generational GC was published in 1984, and I would imagine that it has drastically improved since then. I don't think that generational GC even landed in SBCL until sometime around 2005.
Without anything to back that up, your post just sounds like Lisp fanboyism.
http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/s...
C datastructures most commonly used are Array of structs, Trees and Hashes. Linked lists are not commonly used I imagine. I don't have any stats to back that up though, neither did you.
Out for what?
> CAR/CDR? Let's not.
Works okay even today on a typical Intel 64bit processor.
> The glory days were not that glorious. There are stories out there of runaway garbage collections, that grinded on for days.
Maybe in the early days. Lisp Machine development started in the mid 70s and ended in the early 90s. In the later days its GCs (it provided several different, cooperating GCs) were quite sophisticated.
> Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built.
It won't. Browser GCs are actually not more sophisticated compared to a later day Symbolics GC. The language model of JavaScript is much more primitive than what ran on a Lisp Machine.
Lisp Machines had the same problem like we have today: a hierarchy of memory with different speeds. Very little 'fast' memory, and much much slower, but much larger, virtual memory. Actually the Symbolics Lisp Machines had pretty sophisticated GCs which you even won't find today on typical machines. Caching was all important on Lisp Machines and there was a lot done for that.
A typical Lisp Machine in the Mid 80s had something like 16 MB RAM and 100 MB or more virtual memory on slow disks locally or over the network. End 80s it was 40MB RAM and a couple of hundred MB virtual memory on local disks. Without effective caching strategies this would not have been useful. Some special machines had more RAM, but this was very very expensive.
These machines saved optimized images from which they booted. The memory was sorted according to object types into regions. Lists were converted into a vector-like representation (cdr coding), etc etc.
At runtime a copying GC would move objects around into generations with object-sorted regions, improving locality. An ephemeral GC tracks changed memory in RAM.
Additionally there were a lot of data structures which were under special memory management like networks packets or raster arrays.
EDIT: you seem to have posted a relevant link in another comment as I wrote this one, but I'd love more information if available.
Rather, it's the spirit of the machines - inspectable and programmable from the ground up - that's worth preserving.
This is what made me curious about the Smalltalk-based Squeak VM http://squeak.org/. Its entire interface and stack was inspectable and manipulatable in real time.
In practice it seemed a little buggy, though. If you installed Squeak programs too willy-nilly, pretty soon you'd get errors due to incompatibilities.