Why I Generate Code in Lisp, Not Python

My gut feeling is, this post is 180° wrong. LLMs are the exact opposite of "elite coders", they're perfect StackOverflow users:

* they memorize adapt and write back small-scale patterns very efficiently;

* they know widespread libraries inside out, and can learn others in minutes, even if their doc sucks;

* they often produce good results, because most of the time we write unoriginal code, which paraphrases something it already has dozens of versions of in their training corpus;

* but they're bad at seeing meaningful, non-obvious, simplifying abstractions, we really have to spoon-feed those to them;

* they _love_ verbosity, that's literally how they "think";

* they also love repetition: the other term for "repetition" is "patterns", and they're basically excellent pattern matchers.

So, Lisp is enjoyable for your typical LLM-complementary hacker, but not for LLMs. LLMs typically replace the kind of "non-elite" developers who hated Lisp, for remarkably similar reasons.

What I'd love would be an LLM trained to faithfully rephrase a "normal" program into Lisp-ish pseudo-code, that would make reviews faster, more reliable, more enjoyable. But hand-written code is going the way of hand-written machine code; let LLMs have what suits them best, and higher level tools for the more abstract jobs where we're still relevant, and that would be various forms of code reviews.

As for calling "elite" the kind of developer won't understand that development is a team sports, and that the proper […]

I guess a weakness of the common benchmarks (artificial intelligence, gertlabs, and others) is that, from my understanding, they don't really cater to each language's specificity. If a language such as CL or Clojure boasts a superior REPL experience, that's entirely ignored by benchmarks, because they just look at the result of generic prompting.

So maybe instead of writing countless blog posts on the superiority of such and such language, we should work on improving the benchmarking methodology. Then we would get more useful results.

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 toget […]

Yeah no thanks. Common Lisp is the only language that still brings me joy in a post LLM world and I'd like to keep it that way.

Wrote my first Lisp program in high school 1974; during a teacher's strike some of us geeks bussed it down to the University of Toronto computing centre. It was cafeteria system with a room full of keypunch machines. You typed up your program and got in line with your card deck. The line started with some silos of job cards. You could write fortran, lisp, pl/1, watbol, snobol, etc and run it on an IBM 360 mainframe.

You placed your deck on top of the card hopper when your turn came up. Most programs were 1/2 inch of cards so there were lots of jobs in a hopper that would take two feet of cards.

The line continued until a 1442 line printer at the end where your resulting printout came reeling out at alarming speeds. Operators handed you your printout and you returned to the keypunch room to review your results and make the necessary changes to your card deck.

The cool thing was we were obviously 15 years old and definitely not attending U of T. And our jobs were plainly not for a class because our card decks were 1 1/2 inches thick with long printouts of gameboard configurations.

But nobody ever batted an eye. We went every day for months.

Eventually I went to Uni during the era of the lisp machines. I worked for a professor who got me an office in the cpsc building. He paid me slave wages but the Lisp Machine lab was across from my office so they gave me a key to let people in who didn't have theirs. Bunch of Symbolics 36xx machines running chaosnet. A loud but li […]

I love lisp, but I don't think the syntax is ideal for LLMs because they generate left to right, and lisp is deeply nested by design. Functional languages that have pipe operators and other features to keep code reading left to right, and strong type systems seem like the sweet spot.

I spent quite a while trying to learn Common Lisp and I really wanted to like it, but I’m not sure I’d recommend it. The first problem is finding good learning materials, as most are out of print. On the language side people complain about the parens, which turns out is no big deal. There’s a lot of other weird or needlessly tricky stuff though. The function names are convoluted (e.g. there’s map, but also mapc, mapcan, mapl, maplist). Image based development was interesting, but you might waste an hour debugging because your image diverged from the actual code. Building an actual executable is more complicated than you’d expect, and there’s a lot of magic with packages. There’s some elegance there if you squint, but other lisps are probably better.