Original title: Would you agree that some programming languages are better than others?
Article
The piece argues that Common Lisp is especially suitable for LLM-assisted programming because its image-based, interactive environment minimizes rebuilds, preserves debugger state, and allows code changes to resume execution. Lisp’s homoiconicity and macros also enable domain-specific languages, which the author believes can preserve product-specific design decisions as users customize software. Concise code may reduce token costs and fit more program context into an LLM’s window, while Common Lisp’s stable standard can limit breakage. The author considers its smaller package ecosystem and hiring difficulty manageable because LLMs can write or port missing components and capable engineers can learn the language. The argument assumes these benefits outweigh concerns about runtime performance, infrastructure, maintainability, and the risks of user-directed changes.
Commenters broadly reject the claim that Common Lisp is universally best, arguing that programming languages have different strengths and that static typing, compiler diagnostics, borrow checking, and explicit architecture may help LLMs reason about code more reliably. They note that Python, Node, C#, JavaScript, Smalltalk, Erlang, Rust, and other systems can provide interactive debugging or support domain-specific languages, often with larger ecosystems and better tooling. Several question whether Lisp macros, code concision, or DSLs reduce token use when modular architecture and limited dependencies may matter more. Others raise practical concerns about ERP suitability, missing libraries, extra infrastructure, runtime speed, memory use, hiring, maintainability, macro complexity, code readability, security, and trusting LLMs with powerful customization. A recurring view is that the essay rationalizes a preexisting language preference and provides insufficient evidence for its broad conclusions.