为什么为代码生成选择 Common Lisp？
一篇主张大型语言模型与 Common Lisp 尤其契合——并将其描述为面向“精英黑客”的语言——的博客文章，引发了关于这种精英主义表述以及技术论断的讨论。评论者在 Lisp 适合 AI 辅助编程的优势（如同像性、强大的宏、密集的代码以及交互式 REPL 工作流）与实际缺点（如库稀缺、SBCL 的怪癖，以及模型容易括号不配对或混用 Lisp 方言）之间进行权衡。许多人最终认为，Lisp 确实可能非常适合由专家指导的 LLM 工作流，但语言选择最终更多由团队技能、生态成熟度和经济因素决定，而不是任何固有的“精英”地位。
精英主义、文化与自我描述
- 许多人觉得把 Lisp 或其用户称为“精英”很尴尬或令人反感，通常更倾向于让作品自己说话。
- 也有人捍卫对专业能力的明确承认，并反对他们认为会贬低技能的“民主化”说法。
- 一些人提到长期存在的“傲慢的 Lisp 极客”亚文化，并调侃 Lisp 爱好者尽管主流使用率很低，仍维持着一种小众自我形象。
- 像谦逊这样的文化规范（例如“Jante 法则”）会塑造人们对自我吹捧式语言的反应。
Lisp 真的属于精英吗？
- 一些长期使用 Lisp 的人认为，Lisp 比它的名声更 容易，适合非程序员，甚至适合儿童，而“可怕、精英化”的神话会阻碍采用。
- 也有人承认 Common Lisp 的包袱（历史遗留内容、复杂的函数家族、打包，以及可执行文件构建）很多，并表示其他 Lisp 可能更容易接近。
Common Lisp + LLM：优点、缺点与工具
- 一些人报告说，现代“前沿”模型能生成相当不错的 Common Lisp 或 Clojure；而更老或更小的模型经常混用方言，并且经常括号不配对。
- 工具（括号修复工具、结构化编辑器）和提示技巧（限制嵌套深度、结构化输出）被广泛用来修正括号。
- 有人声称，Lisp 小而规则的语法、密集的代码以及以 REPL 为驱动的工作流与 LLM 配合得很好，能够实现紧密的反馈循环和高效的 token 使用。
- 也有人反驳说，LLM 偏好冗长和重复，难以处理深度嵌套以及像括号这样信息量低的 token，而且在没有人工指导的情况下，很少能发明出好的宏或抽象。
选择 CL 的经济和实践论据
- 一位资深 CL 用户认为，在 LLM 时代，语言选择对性能和代码密度的影响，比对基本正确性或安全性的影响更大。
- 高密度、高性能的 CL 代码可以降低 token 成本和基础设施成本；不过，评论者质疑 LLM 是否会自然地产生这种高密度、宏丰富的代码。
语言选择、安全性与生态系统
- 对于 LLM 是否能像 Go/Rust/CL 那样安全地生成 C 代码存在分歧；有人提到微妙的内存 bug 和近期 LLM 生成的漏洞。
- Go 因其“vibe coding”友好而受到称赞，因为它做事方式几乎只有一种明显的路径，并且拥有强大的标准库，而 CL 的生态系统则被描述为相对稀疏。
- 一些人强调，开发是一项团队活动，工具应该适合团队，而不是个人的语言偏好。
元话题：基准测试、DSL 与替代方案
- 一些人建议当前的代码基准测试忽略了诸如 REPL 工作流之类的语言特定优势，应该加以改进。
- 也有人在主流技术栈（如 Django）中使用类似 Lisp 的 DSL（例如 Hy），并报告说对 LLM 的支持很好。
- 少数人明确希望让 Common Lisp 保持“无 LLM”状态，因为它仍然能给他们带来快乐。