Faré Rideau writes on Lisp, Lisp Machines, operating system design, reflective systems, and political and economic philosophy.
HN commenters cite his pages on PCLSRing and secure Scheme-based capability systems as worth studying, and his Lisp Machine writing.
Ruby is far from an 'acceptable' lisp.
The article's first premise of what are lisp's virtues is dead wrong. First Lisp is NOT a functional language. A functional language is one that maintains referential transparency. i.e. where I can replace the reference/variable with its value its semantics are unchanged. Common Lisp is a multi-paradigm language and pervasively uses the the concept of places to setf state. And in a more general lisp sense, macros are opaque to the run-time and directly opposes referential transparency.
His second statement, Ruby gives you 80% of what you need of macros, implies that we know what macros are for. Macros are not a solved problem, you can see Racket is actively researching macros. For example, how does one do meaningful error reporting in macros? And given that macros, generally, are programming at compile time the statement is as analogous to saying we know what we are programming for, a statement I couldn't disagree more with.
The quid of Lisp I would argue is not specifically macros, but its 'meta-circular semantics', that is to say, the capacity of lisp to speak of itself in a meaningful way[0][1]. For example, in C++ we can speak of C++ but not in C++ but in its template language, that is to say a meta language. Lisp is its own meta language. We could also speak of Python in Python, for example express Python's for loop in python[2], except there is now way to replace python's definition of for with my own.
BTW, that doesn't mean…
> Lisp machines were thoroughly in the "mini"computer (cabinet-sized) category and completely missed out on the microcomputer revolution.
Symbolics and TI both developed microprocessors for Lisp in the 80s. TI promoted their Lisp chip as the 'Megachip' enabling the 'Compact Lisp Machine'. It was the first microprocessor which integrated around a million transistor functions.
Both put the Lisp Machine for example on small Apple Nubus cards and inside an Mac II. The TI MicroExplorer and the Symbolics MacIvory were popular Lisp Machines.
This is a MacIvory board which contains a Lisp processor, a Weitek numerics chip and memory:
http://fare.tunes.org/files/pics/lispm/2003-01-19-lispm-macivory3-kneeled.jpg
A Mac II with a Lisp Machine inside:
https://i.imgur.com/b3XkHpS.jpg
This is a picture of two Symbolics NXP 1000 Lisp machines, which also use Lisp chip:
http://lispm.de/symbolics-nxp1000-inside/thumbnails/IMG_3044.jpg
Basically the size of a typical pizza box machine at that time.
Got one of these myself (in a IIci with a Daystar accelerator and an 8-24-GC video card, 8MW of memory, standard Genera patched for Y2K). It was quite expensive to source and to rehabilitate. Lisp machines are a bit hard to get used to, and I definitely don't claim to be a Lisp deity, but their interfaces demonstrate a great deal of thought and orthogonality that's profoundly missing from a lot of modern UI.
Under the hood the MacIvory implements a Front-End Processor to mimic their workstations. It's a multistage boot: boot the Mac, start the FEP ("Breath of Life"), start Genera. Oddly, while the FEP on real Symbolics boxes is a 68K, the MacIvory CPU handles it directly, sort of like a bootloader.
There's a nice memory dump here: http://fare.tunes.org/LispM.html
That they ended up emulating Genera instead of porting it should tell you something. Maybe. Also, look at the trouble people go through to do that:
http://fare.tunes.org/LispM.html
Then there's this that makes it look easy but also shows the keyboard problem LispM was probably referring to:
http://www.loomcom.com/genera/genera-install.html
What I find on getting them running without LISP hardware is somewhere between tough and "wow, I feel for that person." Maybe things have improved. There just seems to be a huge mismatch between many aspects of LISP machines and modern machines that means it's probably easier to do a clean-slate LISP machine that builds on modern primitives & interfaces better.
I posted these links elsewhere in the thread, but I think they'll be of special interest to HN readers, who might want to know about the more technical aspects of her philosophy.
An index of her thoughts on many topics: http://aynrandlexicon.com/book/conceptual.html
A graduation speech which summarises her views on philosophy in general: http://fare.tunes.org/liberty/library/pwni.html
Her most technical work, her theory of concept-formation (and the book that sold me on her ideas): https://www.amazon.com/Introduction-Objectivist-Epistemology-Expanded-Second-ebook/dp/B002OSXD8C
Much of the memory in a Lisp program is in the form of CONS cells, so the MIT LISP machines had a compact way of encoding this. They also used tagged memory to be able to handle the different kinds of data at runtime. They inherited a very stack-oriented execution model from the PDP-10 implementation of LISP. And they implemented very complex instructions using microcode.
The Symbolics people refined this approach while the LMI people kept the original design until nearly the end when they tried to do a RISC+tags:
http://fare.tunes.org/tmp/emergent/kmachine.htm