The book goes back a bit more, so you'd end at Church :-)
195 karma · joined March 30, 2011
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)
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.
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.
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.
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.
And +1 on a comprehensive Lisp history bibliography, that's a great idea.
_waves a branch_
https://berksoft.ca/gol/genius-of-lisp-chapter-8.pdf has a free chapter.
But you're right, it (and many, many, _many_ other things) does belong in the bibliography.
But, to be honest: Forth is great, but... well... there's no "easy mode" Forth. Whereas there is "easy mode" Scheme - even SICP starts with a very simple and gentle up ramp - so I'd argue to give the honours to Lisp (I'm putting Smalltalk in second place). But that's my personal opinion, I get to put it on my book cover, that's all :-)
It's a history through a lens, but if there is one I'd say "MIT/Stanford" as a central axis rather than a field of reesarch.
And Javascript? My own choice. The amount of "language" I needed was very small and I actually like the very minimalistic (lisp-y?) sort of Javascript you can write these days if you just ignore most of its history. It's accessible, that was more important to me than anything else - one of the few concessions where I wanted to make things digestible to as wide an audience as possible in a language that was good for the problem at hand. Strangely enough, it worked very well (I think).
I heard your (and others') request for a better sample chapter than the intro that Amazon shows, I'll put it on the site as soon as possible.