为什么 Common Lisp 如今是最好的编程语言
这篇文章把 Common Lisp 描绘为“LLM 时代”的理想语言，理由是它基于 image 的活开发模式、强大的调试器，以及可构建简洁领域专用语言的宏系统，这些都可能减少 token 用量并加快智能体驱动的编码。许多回应者提出异议，认为强静态类型（Rust、OCaml、F#、Go 等）、成熟工具链和庞大生态对 AI 辅助开发更重要，而且热重载和交互式调试在其他平台也早已存在。更大的结论是：用于基于 LLM 的编码，并没有出现某一种单一“最佳”语言；语言选择仍然取决于领域、架构和人的可维护性，尽管人们在 Lisp、Python 和其他生态中都报告了令人鼓舞的结果。
调试器、条件系统与热重载
- 许多评论聚焦于 Common Lisp 的条件系统：未捕获的错误可以在不展开调用栈的情况下进入交互式调试器，从而允许更改值或重新编译函数，然后继续执行。
- 支持者认为这缩短了调试循环，即使在编译代码中也能工作，并且在长时间运行的系统或以 REPL 为驱动的开发中尤其强大。
- 批评者认为这在生产环境中有风险（未跟踪的“现场”更改、潜在的坑），而且在实践中，CL 服务器通常也只是像其他语言一样记录回溯并让请求崩溃。
- 还有人指出，其他生态系统（.NET、Java、Dart、JavaScript、Smalltalk）也支持远程调试、编辑并继续或热重载，因此 CL 在这方面并不独特。
宏、DSL，以及面向 LLM 的 token 效率
- 支持 Lisp 的声音强调宏可用于构建 DSL，把领域观点编码进去并大幅缩小代码库，这可能减少 LLM 的 token 使用并提升可读性。
- 其他人则反驳说：
- DSL 自身会带来学习/手工维护开销，并且很容易变成不透明的宏地狱。
- LLM 并不需要 DSL 才能高效，反而可能更偏好训练数据充足、惯例丰富的主流语言。
- 静态、类型化的宿主语言（Rust、OCaml、Lean）也许更适合作为 DSL 平台，因为它们提供更强的保证。
- 关于简洁性和“语言可塑性”是否真的比 LLM 性能中的架构、类型和生态更重要，存在大量争论。
基于图像的开发与智能体
- 有几个人报告说，把 LLM 智能体接到活的 Lisp 系统里（Common Lisp、Clojure、Smalltalk 风格的 image、Janet）效果很好：智能体连接到 REPL，重载代码，运行测试，并在运行中的系统内内省状态。
- 这种工作流被描述为快速且“外星科技”，但也很小众，并且与基于容器的可丢弃部署方式相冲突；也有人发现类似模式在 Python/iPython 或带 autoreload 的 Node 中同样可行。
静态类型 vs 动态类型
- 一派认为强静态类型（Rust、OCaml、Haskell、Scala、F#）对 LLM 尤其有价值：它们像可执行规格说明，提供精确的编译器反馈，约束搜索空间，并帮助大型团队重构。
- 另一些人指出：
- Common Lisp 在运行时是强类型的，并且可以在其上支持静态系统（例如 Coalton 风格）。
- 动态生态可以使用运行时规格、谓词和生成式测试来捕捉丰富的不变量，而这些在许多主流静态系统中并不容易表达。
- 没有形成共识；双方都引用各自偏好的范式下的个人 LLM 经验。
性能、库与安全性
- CL 的性能（尤其是 SBCL）被描述为与其他托管语言相比具有竞争力，但在基准测试中仍远低于经过优化的 C/C++。
- 生态问题：库更少、审计较少；对云 SDK、数据库驱动、ASN.1 等“基础性”组件的支持缺失或较弱。
- 有人认为 LLM 可以低成本移植或重新实现缺失的库；也有人担心会重新碰到各种怪癖、缺少安全审查，以及从零重写带来的 token 成本。
“最佳语言”主张与文章怀疑论
- 许多人拒绝存在单一“最佳”语言的说法，援引偏序和多维权衡；语言选择被看作依赖于领域和组织。
- 多位评论者表示，文章夸大了 CL 的独特性，并低估了其他生态中的类似特性；有人甚至称其为粉丝驱动，或者是 LLM 生成的“垃圾内容”。
- 还有元讨论指出，如今每个社区都在争论他们在 LLM 时代之前最喜欢的语言（Python、Rust、Go、F#、Elixir 等）是“完美的 agentic 语言”，而论据大体对称。
其他
- ERP/DSL 讨论：人们指出，不同行业的 ERP 领域差异很大；语义才是难点，所以 DSL 乃至 LLM 都不会神奇地带来可复用、通用的 ERP 语言。
- 有人因为该链接站点里一个包含色情网链接的不可见 div 而将其标记为可疑，导致公司过滤器把它归类为“成人内容”。