[cdegroot]

When writing a book, you can't make everybody happy. I wrote this for a somewhat general techie audience and already had debates about the amount of math material in the lead-up to LISP I :-). Especially here on HN, there's a better-than-average chance that people will want more, something more encyclopedic, and I get that but "ok for a cross-section of Lisp history" already fills a book, I had to stop somewhere. Too much for some, not enough for others, hopefully "mostly ok" for most readers, it's all I can aim for.

And +1 on a comprehensive Lisp history bibliography, that's a great idea.

[throwaway81523]

> When writing a book, you can't make everybody happy.

The usual reason a reader might be unhappy is that something they wanted to see isn't there. So the solution is put in as much as you possibly can ;). Maybe future editions can be bigger and more comprehensive. OTOH there seems to be quite a lot of what amounts to implementation tutorials. Maybe that's not needed in a history book. In a history book I'm more interested in sources than narrative. Although, some interviews with important Lispers would also be cool.

I can understand not wanting to put in too much math and theory and that's fine. I can't really tell what is there and what isn't beyond getting some hints from the bibliography entries.

This (by McCarthy) showed up immediately when I searched for something unrelated, some articles by Jeff Barnett about Lisp 2: http://jmc.stanford.edu/articles/lisp/lisp.pdf

This is a link dump about Lisp 2: https://softwarepreservation.computerhistory.org/LISP/lisp2_...

I have been wanting to look into Lisp 2 because it had supposedly had an interesting trick in its GC. It was a compacting mark/sweep GC but had an antecedent of generational GC where it usually wouldn't bother trying to reclaim memory that had already survived compaction once. I've been interested in re-implementing that trick in some modern implementations for small MCUs.

[cdegroot]

Didn't know about the planned GC tricks (I mostly treat LISP 2 in passing so it most salient superficial points: the syntax and the fact it never happened), interesting!

W.r.t. tutorials: the most code-rich chapter is the one about "the Maxwell equations of software". As a Smalltalker, I'm well aware of Kay's label of the code in the LISP 1.5 manual. It's a good exercise, especially for non-Lispers, but dare I say also for most Lispers, to implement this stuff to both see how powerful simple ideas can be and to see how this magic works in its bare essence (stripped of "noise" like parsers, etc). The rest is basically illustrations of concepts, and that's on purpose; I wanted to write a history book primarily aimed at techies, so code had to be there.

[pmcjones]

The link dump includes scans of the source code and a link to this free-to-read paper on the history of the Lisp 2 project: https://ieeexplore.ieee.org/document/8267589 (I’m the author).

[kazinator]

Other reasons are:

- what they want is there but not explained or presented in a way that clicks for them

- something is there that they don't want

The latter would be a "WONTFIX". The former is a major difficulty because presenting the same ideas in umpteen ways adds bulk without significant content. If you have the same ideas from every possible angle, it becomes search problem for the reader quickly turning into a TL;DR.