A Road to Common Lisp (2018)

Original Article ↗ Hacker News Discussion ↗

Common Lisp’s appeal in 2024 is framed around its highly interactive, REPL-driven development model, powerful metaprogramming (macros), and stable, extensible core that often reduces dependency headaches compared to many modern ecosystems. Commenters contrast this with more familiar interpreted languages and debuggers, arguing that Lisp environments let you modify running systems, redefine functions, and even reshape object models without restarting, while also noting practical challenges such as editor tooling (Emacs vs Vim/VS Code), uneven library quality (e.g., JSON), and deployment models. The conversation also touches on where Common Lisp and other Lisps realistically shine today—prototyping, web backends, numerical or low-level work—and why, despite strong technical merits and a maturing ecosystem, they remain niche relative to mainstream languages.

Language design, dependencies, and extensibility

  • Commenters argue it’s not contradictory that CL both avoids “dependency hell” and is highly extensible via libraries.
  • The large standard, backward compatibility, package system, and stable libraries mean fewer external deps are needed.
  • Extensibility comes from powerful libraries and macros that can add major features (e.g., CLOS, LOOP) without endless small dependencies.

REPL and interactive development

  • Many contrast Lisp’s REPL with typical “interpreter consoles” (Python, Ruby, R).
  • In CL, the REPL is the running system: you can inspect, redefine functions, change classes and instances, and resume execution in place.
  • Debuggers are REPLs at error points; you can patch code and continue without restarting or recreating state.
  • This is linked to late binding, resident compiler/debugger, and image-based workflows, not just “having a prompt.”

Tooling and editors

  • A recurring pain point is dependence on Emacs/SLIME for the full interactive experience; some users dislike Emacs.
  • Others suggest Doom Emacs / Evil, Spacemacs, Lem, Vim+SLIMV/Conjure, Atom/Pulsar, VSCode (alive-lsp), JetBrains, Jupyter, and browser-based tools like CLOG as alternatives.
  • Some report happily using plain Vim + tmux + REPL; others say the Emacs-based workflow is still uniquely powerful.

Libraries, JSON, and ecosystem

  • Opinions on JSON in CL differ: some see it as a “mess,” others say choosing one library works fine in practice.
  • A newer library, jzon, is mentioned as a de facto standardizing choice.
  • The broader ecosystem is described as richer than many assume, with curated lists and newer projects (web, GUIs, CL-on-LLVM, actors, ML-on-CL, etc.).

Use cases, deployment, and binaries

  • Reported uses include web backends, CLIs, numerical prototyping, games, quantum computing tooling, and Maxima.
  • CL is praised for stable, interactive development and for delivering standalone binaries (e.g., SBCL images), though sizes and toolchains vary.
  • Some prefer other languages (Elixir/Erlang, Rust, C, Racket) for their domains or “batteries-included” feel.

Popularity and learning value

  • Multiple comments ask why Lisp isn’t widespread if it’s so good.
  • Replies emphasize that “best” and “popular” are orthogonal; Lisp’s ideas (homoiconicity, macros) are seen as enduringly valuable even if niche.
  • There’s enthusiasm for Lisp as a way to rethink programming, but also recognition of small community, unfamiliar syntax, and editor friction as barriers.