My favorite languages are Smalltalk and Lisp, but as an Emacs user, I've been using the latter for much longer and for my current projects, Common Lisp is a better fit, so I call myself "a Lisp-er" these days. If people like what I did, I do have plans to write some more (but probably only after I retire, writing next to a full-time job is heard). Maybe on Smalltalk, maybe on computer networks - two topics close to my heart.
And a shout-out to Dick Gabriel, he contributed some great personal memories about the man who started it all, John McCarthy.
(Specific tips on improving the current design welcome, most stores allow edits)
I would say that your choice of cover design as a whole denotes elegance and taste. Look at the cover design of graphic designer Manuel Estrada:
https://estradadesign.eu/project/alianza-editorial/
Your cover remind me of that kind of style.
There are some details about the typeface, layout, and the photograph that, as somebody with a certain background in graphic design, I can perceive as a little bit off.
Those are the kinds of details I was referring to. On the other hand, many computer science covers have historically been quite poor in terms of design, and of course that does not mean much about the quality of the book itself. Some poor covers became memorable and iconic. Some covers are really simple and yet effective like the O'Reilly covers which I particularly like.
Sorry this is going on a tangent unrelated to Lisp. I do like the design of the book cover with the elegant white background. Thanks for writing it, I can't wait to read it.
It's just job conditioning... At some point in my life I was playing the game of trying to recognize the fonts I was looking at in the adds and signs as I walking down the street.
Disclaimer: I'm not a professional, but you did ask ;)
The image on the site has incorrect capitalization ("A History of..."), though the one on Amazon appears to be corrected.
The back blurb hints that expert systems might be mentioned, but how much? No one ever seems to go much into their implementation or usage.[0] It also mentions writing some JS, which I guess is part of chapter 5, I wonder if that was a publisher request. (My favorite take on that subject in recent years is https://github.com/jart/sectorlisp)
Would it be fair to say this is mainly a history told through the lens of AI and PL research?
Amusingly I think part of me is already setting myself up for some disappointment -- it seems too short with too few references! But it's good to have a Lisp history book like this looks to be and I'm sure I'll learn things from it, and the promise of more RPG writings inside is enticing. Besides, any complete telling would take multiple books. (There's so much of historical interest locked up in proprietary applications and companies with their own histories, and so many papers published, there's also so much that can be dug through in the standardization mailing list (and other lists, like emacs) archives[1], the SAIL archives[2], the Xerox PARC archives[3], the CMU archives[4], and the many undigitized things sitting in boxes at the computer history museum...[5])
[0] Norvig's PAIP gives a small taste, one of the files: https://github.com/norvig/paip-lisp/blob/main/lisp/mycin-r.lisp And a book about a particular system, MYCIN: https://www.shortliffe.net/Buchanan-Shortliffe-1984/MYCIN%20Book.htm And a short video: https://youtube.com/watch?v=a65uwr_O7mM
[1] http://ml.cddddr.org/ and http://cl-su-ai.lisp.se/
[3] The url I had before is down... I made a local copy but https://archive.org/details/2014.01.ftp.parc.xerox.com might be the same content
[4] https://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/0.html
[5] Even in the earliest Lisp reports like https://www.researchgate.net/publication/42766480_Artificial_Intelligence there are interesting things mentioned like a two-move checkmate program or "Other projects on which work continues include the Advice Taker, visual pattern recognition, and an artificial hand." Multiple times I've tried to track down those sorts of things mentioned in really old papers only to hit dead-ends on so many of them. Sometimes things were embellished, or were abandoned, or were just lost to time, and sometimes there's an undigitized box at the museum that might contain printouts etc. (There might be MYCIN source code, even.)
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.
That choice absolutely makes sense, once you recall that Brendan Eich was initially hired to write a Scheme! Business and Netscape being what they are, it ended up with Javascript, but there are some lispy roots.
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)
One thing about the sample. Is there a chance to get a glimpse of a random chapter you like a lot? Most of it seems to be foreword/acknowledgement and a bit on "what is lisp" which I suspect most who are attracted might already know.
+1, I'm this close of ordering the hard-cover version, but really hesitant when there is zero samples, not even a page or two, makes it really hard to have any sort of expectation and figuring out if the price is worth it or not.
That can be said about quite a few languages, Forth included. The most powerful != easy to use and/or comprehend.
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 :-)
But thankfully the bibliography is given on the book's Web site in full, so I just checked if the most important paper on the history of early LISP [1] was cited or not. It wasn't, so I'm going to pass on ordering the book's first edition.
But you're right, it (and many, many, _many_ other things) does belong in the bibliography.
https://berksoft.ca/gol/genius-of-lisp-chapter-8.pdf has a free chapter.
Not affiliated, just a happy customer.
Have you seen Behind the Parentheses, by Mark Jones Lorenzo? It goes into quite a lot of technical details about how things like eval/apply were implemented for example, and the larger academic and business contexts eg FORTRAN and earlier language development.
I’m a Lisp newbie (and mostly here for the Emacs Lisp) so a fair amount was beyond me, but I still found it quite readable and interesting.
And a book, which I'd call "an Oldie but Goldie" could be added: John Allen's "Anatomy of Lisp" (1978) which still is an excellent read for those who want to dive deep into Lisp's interna. One might also call it a precursor of SICP, as it covers a number of introductory topics too.
Abstract: https://dl.acm.org/doi/10.5555/542865
John Allen (1937-2022) and Anatomy of LISP https://mcjones.org/dustydecks/archives/2024/04/11/1249/
https://softwarepreservation.computerhistory.org/LISP/book/Allen-Anatomy_of_LISP-1978.pdf
Adding it to the bibliography would be great, I just didn’t like the idea of someone seeing your comment, ordering a used copy of the very old Allen book and not enjoying it.
I will revisit our discussion here in a day or two after I finish reading this book.
Using an accumulation parameter with tail recursion was per Wikipedia introduced in one of the LTU papers, sometime before Scheme. So the description in the chapter is at best imprecise. But, I would want to look further back historically to see whether any Algol compilers used the technique.
Overall the book looks readable as an intro to Lisp and Lisp implementation, but in a history book I'd like to see more precision and depth, careful citations, etc.
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.
It would be awesome to have a comprehensive Lisp history bibliography perhaps built around user contributions, something like Richard Jones's garbage collection bibliography https://www.cs.kent.ac.uk/people/staff/rej/gcbib/ .
And +1 on a comprehensive Lisp history bibliography, that's a great idea.
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_family.html
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.
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.
- 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.
Of course people who experienced things firsthand often have interesting personal as well as technical insight. CHM's oral histories often provide a combination of both. I also always enjoy:
Always loved actors, but unfortunately scheme didn't champion them.
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.
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.
I think you might like this: 'The evolution of Lisp' by Guy L. Steele and Richard P. Gabriel. https://doi.org/10.1145/234286.1057818
I did not think about it too much to be honest, I just knew that article and thought that he would really like it if he had not read it. But I can imagine somebody writing a book on the history of Lisp has already read probably all articles around on the topic.
I just did not think about it for too long.