The Liberating Experience of Common Lisp

Original Article ↗ Hacker News Discussion ↗

Common Lisp’s expressive power, live programming environment, and macro system are praised as uniquely “liberating,” especially for solo developers and exploratory work, but many note its weak libraries, fragmented tooling, and niche status make it hard to justify for most professional teams. Commenters debate whether Lisp really is a “language for smart people,” contrasting its flexible, multi-paradigm style with more constrained languages like Go that favor team readability and strong tooling. Several argue that Lisp shines as a way to learn new ways of thinking about programs or to build long-lived, highly customized systems, while cautioning that ecosystem maturity, collaboration culture, and deployment practices remain significant trade‑offs.

Lisp, “smart people,” and thinking styles

  • Some recall essays calling Lisp a “language for smart people,” but many argue this is wrong or misframed.
  • Several claim Lisp is actually easier to teach than C/C++/Java, especially for beginners.
  • Others say Lisp resonates with particular thinking styles (functional, expression-based) more than with “intelligence” per se.
  • Lisp is also valued as a way to learn new mental models (recursion, symbolic computation).

Comparisons with other languages (Go, Java, Clojure, etc.)

  • Many enjoy Lisp/Clojure for personal or niche professional work, but rarely get to use it in day jobs.
  • Go is praised for forcing readable, straightforward code suitable for “average” teams.
  • Some describe moving from OO-heavy Java/C# to functional Lisps or Clojure as unlocking productivity and clarity.
  • Others enjoy Go or Ruby just as much, and reject the idea that Lisp is a higher “plane of consciousness.”

Power, macros, and maintainability

  • Macros and metaprogramming are seen as Lisp’s superpower but also a risk for abuse and unreadable code.
  • Concern: in flexible languages like Lisp or Scala, teams can diverge on “idiomatic style,” making codebases inconsistent.
  • Counterpoint: any language can produce unreadable “genius” code; discipline and shared conventions matter more than syntax.

Tools, REPL, and live systems

  • The Lisp REPL + editor integration (SLIME/Sly, SBCL, etc.) is repeatedly highlighted:
    • Inspect any function down to implementation.
    • Rich stack traces with live local variables.
    • Patch and recompile functions in a running process and resume execution.
  • Older Lisp machines (e.g., Genera) are cited as the pinnacle of this experience, though some note that similar environments haven’t been widely rebuilt.

Object orientation, state, and paradigms

  • Debate over when OO vs functional style is better:
    • OO seen as helpful for complex interacting stateful entities.
    • Functional/data-oriented approaches seen as better for information processing and business systems.
  • Common Lisp’s CLOS (with optional MOP) is presented as a powerful, different OO model (generic functions, multiple dispatch), not message-passing in the Smalltalk sense.
  • Some argue you don’t need OO for state management; others stress encapsulation and message-style modeling as valuable.

Ecosystem, packaging, and portability

  • Multiple commenters “bounce off” Common Lisp’s dependency and packaging story (Quicklisp, roswell, qlot, ASDF).
  • Complaints: outdated tooling, unclear interactions between per-user and per-project installs, weak versioned dependency resolution compared to modern ecosystems.
  • Some mitigate this with external tools (e.g., Guix) to pin versions, but overall packaging is seen as confusing and under-documented.

Types, safety, and testing

  • Comparison to strongly-typed FP languages (Haskell, Elm, OCaml, Rust): those are said to give a strong “if it compiles, it probably works” feeling.
  • In CL, people rely on tests plus optional SBCL type declarations; some feel this never quite matches the confidence of advanced static types.
  • Coalton (a typed language on CL) is mentioned as an experiment to bring that style of safety into the Lisp world.

Career pragmatics and enjoyment

  • Several distinguish between paid work (in mainstream languages like Go, JavaScript, Python) and hobby or greenfield projects (where they choose Lisp because it’s fun and empowering).
  • Some argue language choice in industry should prioritize team average, ecosystem, and maintainability; others prioritize developer joy for personal ventures.
  • A few wonder whether restrictive or “soulless” languages contribute to developer unhappiness, though others think management and process matter more.

Community and culture

  • Reports of CL community skewing toward “lone wolf” efforts and rewrites for speed or purity, which can be demotivating for collaborative OSS.
  • Others say ego-driven rewrites happen in all ecosystems, but agree that in CL it may be more pronounced.
  • Despite criticisms, many express deep affection for Common Lisp and encourage writing and sharing more real-world experience reports.