Simon Dobson (Posts about project:lisp-bibliography)

A road to Lisp -- Which Lisp?

Simon Dobson — Fri, 07 Aug 2026 08:59:43 GMT

A road to Lisp: Which Lisp?

A blog post reviewing four dialects of Lisp that a beginner wanting to start with Lisp can choose: Common Lisp, Clojure, Racket, and ELisp. The author, Elia Scotto, interestingly doesn't include Scheme, although he does present Racket as a Scheme dialect (which of course it is).

Does the choice too make initially matter?

Dialect matters, but not as much as a beginner might think. Learning Lisp is about learning a new type of programming. A new way of thinking about problems using code. You will learn the fundamental concepts with any dialect. Then, once you have learned one, it will be relatively easy to switch to another.

I think most Lisp devotees would agree with the sentiment that it's about a new relationship with code; I'm not totally convinced that Racket is a good place to start, given that it's essentially several languages; and ELisp only makes sense if you are already a devoted Emacs user, otherwise the learning curve will be nearly vertical.

Scotto's conclusion is that Clojure is the safest first choice, giving you a modern syntax and full-stack environment with access to all the Java libraries, while Common Lisp gives you fast native compilation within a large, stable, and rock-solid ecosystem, and Racket is a good basis for language research.

For my own part I came to Scheme first when I was an undergraduate, then picked up ELisp when I started using Emacs, and then learned Common Lisp when I started wanting to write significant code – and there I've stayed with the latter two, quite happily. It's certainly the case that it's been easy to move between these dialects, modulo some differences that are purely syntactic. And it's certainly true that Lisp changed my relationship to code in a deep and persistent way.

Beautiful Racket: An introduction to language-oriented programming using Racket

Simon Dobson — Tue, 14 Jul 2026 07:07:51 GMT

Beautiful Racket: An introduction to language-oriented programming using Racket

Matthew Butterick. Beautiful Racket: An Introduction to Language-Oriented Programming Using Racket. 2024.

Racket positions itself as a "programmable programming language" – more so than Lisp's usual claim to this title – which makes it attractive for exploring multi-paradigm and multi-language programming.

Racket's main claim to a niche is allowing a programmer to define new domain-specific languages (DSLs), not necessarily Lisp-like, that can be combined together to let a program be expressed in the "most appropriate" form for the problem. This books is structured around exactly this idea, defining a succession of languages of increasing sophistication to demonstrate Racket's capabilities. Each language has a "reader" to convert strings into Lisp S-expressions and an "expander" to translate these forms into Racket (or another Racket-defined language). The examples include a simple stack-based calculator, an embedded JSON parser, and a Basic interpreter that exercises the power of a full parser.

The description of Racket itself is very thorough, to the extent that this book could be treated as a language definition itself, complementing the article about it. Certainly it provides the most accessible way to learn the language and explore what it means to explore "language-oriented" programming.

It's possible to define DSLs in Common Lisp or Scheme without Racket's extra functionality, and in many cases that will be sufficient – especially when the DSL is a Lisp itself. But there will certainly be applications for which Racket is absolutely the right tool.

A programmable programming language

Simon Dobson — Fri, 10 Jul 2026 14:44:09 GMT

A programmable programming language

Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi, Eli Barzilay, Jay McCarthy, and Sam Tobin-Hochstadt. A Programmable Programming Language. Communications of the ACM 61, pp.62–71. 2018.

Lisp has been described as a "programmable programming language": the fact that Lisp code is valid Lisp data and can be manipulated as such, coupled with macros, makes it easy to construct new Lisp variants in Lisp, and to combine them with "real" Lisp in interesting ways.

Racket is a Lisp that takes this to its logical conclusion, making domain-specific sub-languages into first-class objects that can be freely interleaved within programs and can be matched to the "natural" expression of the target domain. The languages don't even have to be Lisp-like.

In the ideal world, software developers would analyze each problem in the language of its domain and then articulate solutions in matching terms.

Racket languages are formed of two parts: a reader that turns strings into properly bracketed S-expressions, and an expander that turns these expressions into "real" Racket (or some other Racket-defined language).

This flexibility adds a whole new level to Lisp programming. For example, it allows languages that don't readily translate to Lisp style to be implemented and integrated into Lisp. This may simply be for user convenience, or may have some deeper semantic structure. Racket also defines clean interfaces between languages, which is what allows them to be combined. It's a deeper version of the usual Lisp multi-paradigm approach, reaching out beyond macros working on Lisp syntax.

The Lisp curse

Simon Dobson — Thu, 18 Jun 2026 09:07:24 GMT

The Lisp curse

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.)

Programming algorithms in Lisp

Simon Dobson — Sat, 13 Jun 2026 11:15:03 GMT

Programming algorithms in Lisp

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.

Modern Common Lisp with FSet

Simon Dobson — Fri, 12 Jun 2026 08:56:40 GMT

Modern Common Lisp with FSet

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

Simon Dobson — Fri, 22 May 2026 11:47:12 GMT

A Lisp interpreter implemented in Conway's Game of Life

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.

Common Lisp screenshots

Simon Dobson — Fri, 22 May 2026 11:46:17 GMT

Common Lisp screenshots

https://www.lisp-screenshots.org/

A collection of links to Common Lisp applications, including utilities, games, and full-blown science packages and web applications. Most have links to the applications' home pages.

The Common Lisp cookbook

Simon Dobson — Fri, 22 May 2026 11:45:13 GMT

The Common Lisp cookbook

https://lispcookbook.github.io/cl-cookbook/

Part tutorial and part recipe site for topics ranging from the common (syntax, the loop macro), to the advanced (packages, multi-threaded web application programming, building stand-alone binaries). It's extremely thorough in terms of the patterns used in real Lisp code.

I think the most useful aspect is that the recipes go well beyond what's built-in to Lisp and tackle some of the common (and not-so-common) packages: the chapter on arrays goes into a couple of linear algebra packages, for example. It also has useful chapters on development tasks like profiling and continuous integration.

Lush

Simon Dobson — Thu, 30 Apr 2026 14:03:14 GMT

Lush

Lush: my favorite small programming language

A blog post all about Lush, a small language that the authors present as a "Lisp Universal SHell" whose main features are its ability to integrate simply with underlying libraries with the interactivity of Lisp. And it's a full Lisp, with a compiler, a macro system, an object system, and (importantly for what comes next) high-performance arrays and tensors.

Lush's main claim to interest is that its authors include Yann LeCun, Yoshua Bengio, and the other researchers who went on to have a massive influence on the resurgences of interest in deep learning neural networks. Indeed, the first version of the Torch package, which later became PyTorch, was written in Lush. Lush's arrays make use of a sub-language modelled on APL that leverage Lush's ease with foreign functions to call into underlying C kernels for tensor operations.

This is a great example of how Lisp's claim to fame as a language for doing AI has continued into the "new" AI era of deep learning models. It also shows that, if you believe that Lisp's dynamism and flexibility are an advantage to you, there are no barriers to continuing to benefit from that even if you need to access a wider ecosystem of tools. It'd be interesting to understand the performance trade-offs in this: what is the performance of a Lush algorithm that makes extensive use of its array language, and how can this performance be maximised using higher-level language constructs of the sort Lisp encourages?