https://www.winestockwebdesign.com/Essays/Lisp_Curse.html

The power of Lisp is its own worst enemy.

An interesting essay on the “Lisp curse”, the idea that Lisp’s power can sometimes be a disadvantage for developers. The core idea expressed as a question: how hard is it to add object-oriented features to a language? In the C world it’s happened twice, giving rise to C++ and Objective-C, an no-one would even think about defining their own. In the Lisp world, by contrast, building that style of object-oriented extension is a weekend’s work (assuming we didn’t already have CLOS, which is in many ways superior anyway). The point is that it’s relatively easy to build even complex features as libraries, meaning there’s less reason to standardise, and this leads to a proliferation of mutually incompatible designs that solve 80% of the problem – but all a different 80%. This then makes interoperability difficult.

In fact the essay goes farther, to argue that the sorts of people who write Lisp tend not to be the sorts of people of work well in the political and compromise-driven world of standardisation. I’m not sure how true that is, given the stability of the Common Lisp standard itself since its adoption in 1994, but it’s an interesting reflection on how increased language expressiveness need not automatically be a strength.

(Some of the links in the article are now broken, or point to what looks like an AI link farm.)

Vsevolod Domkin. Programming Algorithms in Lisp. Apress. 2021.

This is exactly what it sounds like: an algorithms textbook that uses Lisp as its implementation language. It has the strengths and weaknesses of all such textbooks: it shows programmers, especially new programmers, how to write algorithms that are both correct and efficient, and the places where incorrectness and inefficiency will hide; and in doing this it tempts them to write algorithms that are already implemented in libraries, when they should really seek out and re-use the already-developed and -debugged code.

But of course there are always new algorithms that don’t have an existing library and therefore need to be written from scratch. This book is excellent preparation for that. It would give a new-ish programmer the confidence to tackle a challenging algorithm design and implementation job. It ranges well away from the common algorithms, to cover things like approximation and (especially importantly) parallelism and lock-free data structures, and I can imagine it providing templates that could be used as starting points for a huge range of new algorithms. Just remember not to re-invent the wheel.

https://fset.common-lisp.dev/Modern-CL/Top_html/index.html

A book-length description of a library, FSet, that provides functional collections for Lisp. By “functional collections” the author means collections – sets, trees, maps, and others – where update always produces a new collection rather than mutating the original collection in place. This is an attractive property for a language, and one that’s hard to do efficiently. As with Purely functional data structures, it provides a change of emphasis that makes for more referentially transparent code.

The book contains a lot of discussion about the library’s rationale and design, which makes it useful as a reference for others designing large libraries (or new languages, which of course in Lisp can mean much the same thing). There’s an equally important discussion about what’s not provided (for example lazy collections) which is really interesting by giving an example of when to stop with a codebase that could otherwise probably grow indefinitely.

A Lisp Interpreter Implemented in Conway’s Game of Life

I include this as an application rather than an implementation technique because … well … it’s far more interesting as an example of cellular automata (CAs) than as a Lisp.

Having said that, there’s something utterly compelling in watching a CA run something this complicated. It basically implements a Lisp machine core, and watching it execute is rather like watching a real chip in action (even though the mechanisms are completely different). You can see memory being accessed. Its implementation includes lexical closures, enough to build a simple object system.

The implementation uses the VarLife system as an abstraction layer over the “raw” Conway rules. The compiled programs can be run on the Golly CA emulator.