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.

I'll never understand why people post LLM outputs in forums pretending they wrote it themselves.

You asked Claude or some other agent to make your argument for you, and what you got was a well formatted pile of nothing. Bravo.

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