Why Target Common Lisp for Code Generation?
A blog post arguing that Large Language Models pair especially well with Common Lisp—framing it as a language “for elite hackers”—sparks debate over both the elitist framing and the technical claims. Commenters weigh Lisp’s strengths for AI-assisted coding, such as homoiconicity, powerful macros, dense code, and interactive REPL workflows, against practical drawbacks like sparse libraries, SBCL quirks, and models’ tendency to mis-balance parentheses or mix Lisp dialects. Many conclude that while Lisp can be an excellent fit for expert-guided LLM workflows, language choice is ultimately driven more by team skills, ecosystem maturity, and economic considerations than by any inherent “elite” status.
Elitism, Culture, and Self-Description
- Many find calling Lisp or its users “elite” cringey or off-putting, often preferring work to speak for itself.
- Others defend explicit acknowledgement of expertise and push back on “democratization” that they see as devaluing skill.
- Several note a longstanding “smug Lisp weenie” subculture and joke that Lisp enthusiasts maintain a niche self-image despite low mainstream usage.
- Cultural norms like humility (e.g., “Law of Jante”) shape how people react to self-aggrandizing language.
Is Lisp Actually for Elites?
- Some long-time Lisp users argue Lisp is easier than its reputation, suitable for non-programmers and even children, and that the “scary, elite” myth harms adoption.
- Others acknowledge Common Lisp’s cruft (historical accretions, complex function families, packaging, and executable building) and say other Lisps may be more approachable.
Common Lisp + LLMs: Pros, Cons, and Tooling
- Several report that modern “frontier” models generate decent Common Lisp or Clojure; older or smaller models often mixed dialects and frequently misbalanced parentheses.
- Tools (paren-repair utilities, structural editors) and prompting tricks (limit nesting depth, structured output) are widely used to fix parentheses.
- Some claim Lisp’s small, regular syntax, dense code, and REPL-driven workflows pair well with LLMs, enabling tight feedback loops and efficient token usage.
- Others counter that LLMs favor verbosity and repetition, struggle with deep nesting and low-information tokens like parentheses, and rarely invent good macros or abstractions without human guidance.
Economic and Practical Arguments for CL
- One substantial CL user argues that with LLMs, language choice matters more for performance and code density than for basic correctness or security.
- Dense, high-performance CL code could lower both token and infrastructure costs; however, commenters question whether LLMs naturally produce such dense, macro-rich code.
Language Choice, Safety, and Ecosystem
- Disagreement on whether LLMs can produce C code as securely as Go/Rust/CL; some cite subtle memory bugs and recent LLM-generated vulnerabilities.
- Go is praised as “vibe coding” friendly due to one obvious way to do things and a strong standard library, while CL’s ecosystem is described as comparatively sparse.
- Some stress that development is a team activity and tools should fit the team, not individual language preferences.
Meta: Benchmarks, DSLs, and Alternatives
- Several suggest current code benchmarks ignore language-specific strengths like REPL workflows and should be improved.
- Some use Lisp-like DSLs (e.g., Hy) within mainstream stacks (like Django) and report good LLM support.
- A minority explicitly want to keep Common Lisp “LLM-free” because it still brings them joy.