I spent the last year writing substantial Common Lisp, including a FoundationDB client and distributed systems primitives layered on top of that, an observability and operability library for CL systems, and a large scale log, metrics and tracing platform that leverages these - in about 200K lines of code and tests. My take on this, apart from one of familiarity and personal preference/taste in choosing a programming language, in the age of LLMs are - 1. From a “functional requirements” perspective, any language will do. You can build substantial systems in something low level like C or higher level like Python or Common Lisp for example. 2. From a security perspective, if you are using LLM assisted code generation, whether you use C or Rust or Common Lisp does not really matter I think - current models are capable, and future models perhaps more so, in producing secure code.

My understanding is that LLM are deflationary, resulting in code being priced as a commodity (cost plus). If this bears out, then lower token costs and higher performance (esp in my case, where good performance results in lower infra costs to host the service) will start to matter more and more. Common Lisp code bases are famously dense (in the good sense), resulting in perhaps lower token costs when an LLM needs to review and make a change (smaller code bases also help humans / small teams). Common Lisp can achieve performance that’s close to that of an equivalent implementation in C or C++.

Taken together, they make for one case for using CL and other similar languages, although one that’s grounded largely in economics.

I’m fascinated that some people in our field choose to self describe themselves as “elite”.

Are there any programming/computer science greats that self aggrandize like this? Is it a cultural thing somewhere that I’m not aware of?

I have been using cl for a project recently, as it had many features I wanted and actually made sense to use despite not being familiar with it (though used elisp and a tiny bit of scheme). I found it mixed some things where fantastic some things remain pain points, SBCL is a fantastic project and compiler and once you get used to the debugging it's a very nice experience with slime. It is true to say that it's flexibility is fantastic and CLOS object system once you get used to it is very nice. On AI assisted coding I found it mixed and though Claude now seems quite good at it, local models can be quite poor and lots of things are a lot less well documented and the fact that there is less code out there. One thing to look out for with local models (and probably even the frontier models but with there larger size negates the issue entirely from my usage) is that '(' or ')' might be part of a token such that '))' is a discrete token and '(*' might be as well, all that is to say that when it writes code terminating and start blocks can be an issue so your parens will be off, this was when using omnicoder 9B and that was the main issue. not sure how more recent local models function as switched to claude for part of it and tended to prefer to take my time and write the code myself.

I don't know if anything has changed, but last time I tried codegen for Common Lisp, the LLM would routinely mix up LISP dialects and language specific features.

Less so with Clojure.

One annoying part of SBCL is that it does something up front with its memory such that if you run it with an 8GB heap, running shell commands takes a noticeably long time even for "echo hi". It’s something to do with the way it forks. Shell commands are also serialized, meaning multiple threads running curl won’t help you more than a single thread running curl. This is in contrast to almost every other programming language, which lets you get more performant network fetches by running the requests in multiple threads. The only alternative to curl is to use a library that simulates curl or write your own, which is fraught with errors: if any piece of the connection times out, it has to gracefully terminate, which is harder than it sounds when you’re interfacing with OpenSSL directly.

I think that covers my list of grievances though, and it’s a pretty short list. Other than those, CL has been good to me.

>I do not operate the LLM in a sterile text editor. I operate it from within a Lisp REPL

I'd be very interested in reading more about this.

Was going to write something about the article but then poked around the blog and it led to Github including this gem: https://github.com/jrm-code-project/llambda which is much more interesting.

I do agree with a lot of the article though, Lisp plays nicely with LLMs. Definitely had better luck with Lisp and LLMs than C++ or Rust.

Also, kind of random, but here's an interesting tool to use CL with LLMs: https://www.lambda-symbolics.com/autolith

Counterargument—weaknesses of Lisp:

1. The author's first argument is that CL is familiar to them—fine. However, this does not translate into any benefits for the model and is not generalizable.

2. The second argument is that HLLs are an unqualified good, and again that they reflect the desires of the author. It's certainly true that having less boilerplate to manage reduces the surface area for mistakes, and makes code easier to review, but this is only a very weak argument in Lisp's favor. Given the right library, most HLLs can be as flexible as Lisp, especially newer ones where questions about standard library design and collection behavior are still being explored. Conversely CL's standard library is indebted to decades of history. No racehorse wins races forever.

3. The third argument is that Lisp was somehow intended for exclusive use by qualified individuals—this is absolute brainrot. It was designed to manage recursive structures on an IBM 704, and that's about it. It then repeats an unrelated statement about CL being 'built for maximum expressiveness', calling back to the second point; it has been surpassed.

4. The fourth argument trots out the infamous dead horse of homoiconicity. Parentheses have low information density. The LLM wastes a huge amount of context on indentation already, and to have only one style of parenthesis for the vast majority of code is contrary to its expertise. If you want to claim homoiconicity as an advantage, then you need to make your model generate an actual tree data structure, not indented, linear, parenthetical strings. LLMs cannot do this; the harness required defeats the benefit. Therefore point 4 is totally wrong. Homoiconic languages are only of value when you need something that resembles the intermediate state of a compiler—i.e., for macro transformations. The Markov-model-like architecture of an LLM does not benefit from this property whatsoever.

5. Next the author brings up using macros to form a DSL. If the macro is shallow (i.e. it doesn't perform deep syntax transformation) then it is just syntactic sugar and could be a function. If the macro is deep (i.e. it restructures all kinds of stuff) then you are putting a cognitive burden on the LLM to keep track of which syntactic rules apply, and the risk of failure goes up.

6. The author mentions that REPLs exist. This is, again, an example of wearing blinders. REPLs are so common and so good now that even web browsers come with better JS REPLs than a command-line.

7. The author thinks it is amazing when a development environment triggers a breakpoint instead of crashing on a failure. This feature is so standard that even gdb and MSVC do it. Visual Basic, famously, did it quite well.

8. Hot-reloading functions: This is, again, possible in a wide variety of languages, though not always as a default feature. For example, IPython adds this behavior to Python. Hot-reloading is not widespread because it often results in inconsistent program state.

Virtually all of CL's strengths are outmoded or defeated by giving the job of programming to a machine. It's like putting velvet inside your toilet tank: sure, it's fancy, but nobody benefits.

Even more importantly, though, the pool of available training data for CL is vanishingly small compared to other languages, which will increase the error rate dramatically. You should expect a lower quality of code for CL, and a high frequency of it being confused for similar, more popular languages like Scheme and Clojure. LLMs actually excel at Clojure, in part because its syntax is crunchier. All that sugar—applied consistently across the language, not sporadically in a rare DSL macro—helps the LLM keep track of what it's doing and where it is.

In short: sunk cost fallacy.

> Conversely CL's standard library is indebted to decades of history.

There's no such thing as "CL's standard library." I presume you mean the functions built into Common Lisp which provide basic functionality, but nobody uses "bare" Common Lisp any more than anybody uses bare C. The Quicklisp libraries for CL (among others) provide the modern utilities you seem to think CL lacks.