拥抱现代世界中的 Common Lisp

原文 ↗ Hacker News 讨论 ↗

Common Lisp 的现代相关性被拿来与 Clojure 和基于 JVM 的语言比较，许多人称赞 SBCL 的新垃圾回收器、库部署选项以及 Coalton 等项目，同时也抱怨编辑器集成薄弱、文档不均衡和 GUI 工具过时。评论者讨论 Clojure 这种以 Java 为中心、动态类型、托管式的模型及其生态访问能力，是否足以抵消其 JVM 开销、棘手的堆栈跟踪，以及对底层平台知识的依赖。该线程还涉及关于“更绿色”语言的环境论点、强大的商业 Lisp IDE 与 Emacs+SLIME/SLY 等开源工具之间的权衡，以及关于性能、可调试性和托管运行时相对于自包含运行时的长期可行性的更广泛问题。

Common Lisp 生态系统的发展

  • SBCL 正在积极演进：新的并行和并发垃圾回收器已进入 beta，旨在减少停顿并利用多核 CPU。
  • SBCL-LIBRARIAN 通过将其部署为与 C 兼容的共享库来改进部署，便于 C/Python 互操作，无需 RPC。
  • Coalton 增加了一个类似 Haskell、Lisp‑1、静态类型的层，带有类型类和类型推断；持久序列（RRB 树）提供类似 Clojure 的 seq。
  • 这些创新中的许多是由用户，而不是委员会，推动的。

Common Lisp 与 Clojure 以及托管在 JVM 上的 Lisp

  • 许多人认为 Clojure 是最主流的“现代” Lisp，但也有人认为 Emacs Lisp 的用户可能更多。
  • 对 Clojure 的反对意见包括：JVM 的臃肿和内存占用、动态类型、以 Java 为中心的库和堆栈跟踪、对宿主知识的依赖，以及托管语言的脆弱性。
  • 有些人欣赏 Clojure 的不可变数据结构、STM、spec 以及 Java/.NET/JS 互操作，但认为 Java 生态是一种浮士德式交易。
  • 提到的替代方案包括：Clojure CLR/Script/ERL、Basilisp（运行在 Python 上的 Clojure）、JVM 上的 Armed Bear CL，以及 BEAM 上的 Lisp。

工具、编辑器和调试器

  • 除了 Emacs 之外，Common Lisp 的编辑器支持（VS Code、JetBrains、Atom/Pulsar、Lem、Geany 等）是存在的，但常被认为不完整或不稳定。
  • 一些人认为 Emacs + SLIME/SLY 极其强大；另一些人则觉得它与经过打磨的商业 IDE（Allegro、LispWorks）或主流调试器（Visual Studio、Smalltalk）相比显得笨拙。
  • 对于 CL 的 REPL 驱动风格是否减少了对“现代” GUI 调试器的需求，存在分歧。

文档与学习曲线

  • 有几位观点认为，最大的采用障碍是库文档质量差且不一致，而不是编辑器。
  • CL 的自省能力（DESCRIBE、跳转到源代码）在一定程度上弥补了这一点，但也形成了一种读代码而不是写文档的文化。

性能、效率与“绿色”论点

  • 有些人声称 Common Lisp（尤其是 SBCL）可以更轻量，并且与 JVM 语言一样快甚至更快，特别是在启动和 CPU 密集型代码方面，因此更“绿色”。
  • 另一些人对这种环境论点表示怀疑，认为从 Clojure 切换到 CL 在数据中心能耗上的收益可能很小，而人力时间成本也同样重要。
  • 关于基准测试以及 JVM vs CL vs C/C++ 的性能存在争论，但没有明确共识。

GUI 与桌面应用

  • 自由 Common Lisp 缺乏主流的跨平台 GUI 方案。
  • 提到的想法和项目包括：围绕 CL Web 应用的 Electron/Tauri 风格封装器、McCLIM（功能强大但尚不成熟且偏向 X11）、CLOG、Ceramic（基本无人维护），以及作为浏览器内 CL 环境的 Nyxt。