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 couldn’t help but notice the parent commenter’s post history. Account from literally before this was called HN, one comment 6 years later, then 13 years later this comment.

The pro lisp/s expression comments check out.

But will an LLM write dense Common Lisp? A lot of that density comes from well-designed domain-specific macros. An LLM will have no incentive to write these on its own, though it could if a human prods it sufficiently.