cdegroot

The book goes back a bit more, so you'd end at Church :-)

Yup. They have a lot of resources available on how to do it but what gets printed is 100% the author's (or publisher's) responsibility.

I went for the somewhat humbler reasons of "I can assume that my reader will know it at least a bit" and "simple to obtain" - a bunch of the examples will run in the browser :-)

But yes, JS' dynamic/LISP-y roots did make my examples simple to implement and thus simple to follow. No trickery was needed, it was all pretty straightforward.

(JS is a much maligned language and for very good reasons, it had a shaky past and still is too full of warts that should be excised at some point. But modern JS with the help of modern IDEs isn't actually _that_ terrible and traits like it being prototype-based make some otherwise complicated things easy)

It's... "different". I think there are two big things going on: one is the fact that "refactoring" never ends, as you can mold the language around your problem. Ultimately that level of expressiveness makes the hard parts of your code more concise, more readable (as the code ends up being closer to the domain at hand), and therefore more maintainable.

The other thing, which it shares with Smalltalk and which I've seen pretty much nowhere else (Erlang comes very close) is the interactivity. You code inside a running system. Yes, other languages have things they call "the REPL", but they can't deal with classes changing shape, reloading code, etc. It makes the coding cycle much shorter, quicker feedback is better feedback, so you end up going faster (and iterating through complex stuff like that macro that will really nail how clean your top level code is will be much more doable)

When I mentor coders, I often talk about malleable code, like the clay on a potter's table. As soon as you stop working it, things start solidifying and your code turns into something unchangeable and brittle. I think Lisp's traits (which I otherwise only found in Smalltalk) help you push back that point, maybe indefinitely.

Absolutely not. I created every mistake painstakingly by hand ;-)

Yeah, you can't imagine how happy I was when first RPG sent me some of that material to help me out with background and then said yes when I asked him for permission to include them verbatim in my book. He's such a good writer.

Thanks. An initial list of errata will appear this weekend (probably tomorrow). I think I'll add a RSS feed for it :)

W.r.t. actors and scheme: the whole thing is that Sussman and Steele started Scheme to figure out actors, did some hacking to do async stuff on top of Maclisp, essentially, and then found out that their stuff and (Hewitt-style) actors were the same. So I guess Scheme took "the same but a different" path early on, pretty much how Erlang and Golang are pretty much similarly powerful systems, expressing the same functionality in different ways.

Yup, and the book mentions that, including the surprising result that (Hewitt-style) actors - which are not completely like Erlang processes - and Scheme's closures were the same.

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.

Thanks. Even though I'm originally from Europe, the book has ended up somewhat focused on what happened on the continent where I now live. It's something I'm planning to fix for a potential second edition.

Turns out that for me, Shopify was even easier, so that's sorted now. In any case, thanks for pushing me into the right direction.

Darn, I had his name wrong and fixed it, but somewhere an undo button must have been hit. Thanks for pointing it out.

I'm more than happy to add corrections to an already "longer than zero" list of errata. I'll give the Scheme chapter and Wikipedia a once-over to see where I went off the rails.

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.

These days it's all "I am Groot" :-)

_waves a branch_