Embracing Common Lisp in the modern world

Original Article ↗ Hacker News Discussion ↗

Common Lisp’s modern relevance is weighed against Clojure and JVM-based languages, with many praising SBCL’s new garbage collectors, library deployment options, and projects like Coalton while lamenting weak editor integration, uneven documentation, and dated GUI tooling. Commenters debate whether Clojure’s Java-centric, dynamically typed, hosted model and ecosystem access outweigh its JVM overhead, tricky stack traces, and dependence on underlying platform knowledge. The thread also touches on environmental claims about “greener” languages, the trade-offs between powerful commercial Lisp IDEs and open-source tools like Emacs+SLIME/SLY, and broader questions about performance, debuggability, and the long-term viability of hosted versus self-contained runtimes.

Common Lisp ecosystem developments

  • SBCL is actively evolving: new parallel and concurrent garbage collectors are in beta, aiming to reduce pauses and exploit multicore CPUs.
  • SBCL-LIBRARIAN improves deployment as C-compatible shared libraries for C/Python interop without RPC.
  • Coalton adds a Haskell-like, Lisp‑1, statically-typed layer with type classes and inference; persistent sequences (RRB-trees) give Clojure-like seqs.
  • Users, not committees, are driving many of these innovations.

Common Lisp vs Clojure and JVM-hosted Lisps

  • Many see Clojure as the most mainstream “modern” Lisp, but others argue Emacs Lisp may have more users.
  • Objections to Clojure: JVM bloat and memory footprint, dynamic typing, Java-centric libraries and stack traces, reliance on host knowledge, and hosted-language fragility.
  • Some appreciate Clojure’s immutable data structures, STM, spec, and Java/.NET/JS interop but see the Java ecosystem as a Faustian bargain.
  • Alternatives mentioned: Clojure CLR/Script/ERL, Basilisp (Clojure-on-Python), Armed Bear CL on JVM, and BEAM Lisps.

Tooling, editors, and debuggers

  • Common Lisp editor support beyond Emacs (VS Code, JetBrains, Atom/Pulsar, Lem, Geany, etc.) exists but is often seen as incomplete or unstable.
  • Emacs + SLIME/SLY is viewed by some as extremely powerful; others find it janky compared to polished commercial IDEs (Allegro, LispWorks) or mainstream debuggers (Visual Studio, Smalltalk).
  • Disagreement over whether CL’s REPL-driven style reduces the need for “modern” GUI debuggers.

Documentation and learning curve

  • Several argue the biggest adoption blocker is poor, inconsistent library documentation, not editors.
  • CL’s introspection (DESCRIBE, jump-to-source) partly compensates, but creates a culture of reading code instead of writing docs.

Performance, efficiency, and “green” arguments

  • Some claim Common Lisp (esp. SBCL) can be lighter and as fast or faster than JVM languages, especially for startup and CPU-heavy code, and thus “greener.”
  • Others dispute the environmental framing, arguing datacenter energy gains from switching Clojure→CL are likely tiny, and human-time costs matter too.
  • Benchmarks and JVM vs CL vs C/C++ performance are debated, with no clear consensus.

GUIs and desktop apps

  • Free Common Lisps lack a mainstream, cross-platform GUI story.
  • Ideas and projects mentioned: Electron/Tauri-style wrappers around CL web apps, McCLIM (powerful but immature and X11-focused), CLOG, Ceramic (largely unmaintained), and Nyxt as a CL-in-a-browser environment.