Lisp: Notes on its Past and Future (1980)

Original Article ↗ Hacker News Discussion ↗

Clojure vs. Rust and Other Language Choices

  • One thread explores choosing Clojure instead of Rust for “non-low-level” work, arguing both target shared-mutability problems but with very different approaches.
  • Others suggest alternatives like F#, Elixir/Erlang, or Scheme/Common Lisp depending on needs (static vs dynamic, systems vs app code, commercial ecosystem).

State, Concurrency, and Performance Models

  • Several comments contrast Rust’s ownership/borrow checker with FP-style immutability (Clojure, Elixir, Erlang):
    • FP/Lisp-style: avoid shared mutable state by using immutable data and persistent data structures; easier mental model, some runtime overhead.
    • Rust: allows mutability and sharing but not simultaneously; compiler-enforced safety at cost of a steeper learning curve.
  • Some note Clojure’s Software Transactional Memory is rarely used in practice; persistent data structures are central.
  • Anecdotes suggest Rust can significantly outperform Clojure when raw performance (e.g., games) is critical.

Clojure, JVM, and Ecosystem Health

  • One side claims Clojure and the JVM are “looking dead”; others strongly dispute this, citing:
    • Active JVM evolution (e.g., virtual threads).
    • Ongoing Clojure community activity and variants (ClojureScript, ClojureCLR, ClojureDart, babashka, jank).
  • Disagreement over whether Clojure benefits strongly from the Java ecosystem: some praise effortless reuse of mature Java libraries; others feel the JVM brings cultural and tooling friction.
  • Clojure is seen as commercially niche but real; Common Lisp is described as more “eternal” but with a sparser ecosystem.

Lisp Developer Experience (REPL, Live Systems)

  • Multiple comments emphasize that the distinctive value of Lisp/Clojure is not just language features but the REPL-driven, live-editing workflow:
    • Code is edited in normal files, but forms are evaluated directly into a running system.
    • This encourages incremental development, rich introspection, and reduced edit–compile–run cycles.
  • Comparisons are drawn to Smalltalk and iPython; some say this style changes how you think about structure and state.

Why Lisp Isn’t Mainstream

  • Theories include:
    • Most programmers find imperative/OO easier to “grok” than functional styles.
    • Mainstream languages have absorbed key FP features, reducing the incentive to switch.
    • Productivity depends heavily on libraries/frameworks; Lisp ecosystems often lag in breadth.
    • Lisp’s extreme flexibility and powerful metaprogramming make large-team maintenance harder, especially with less-experienced developers.
  • Others argue Lisp supports multiple paradigms and is used successfully in commercial settings; the barrier is social and educational, not inherent.

Lisp, AI, and McCarthy’s “Higher-Level Than Lisp”

  • Discussion connects McCarthy’s prediction of declarative, goal/fact-based programming to:
    • Prolog-style logic programming.
    • Modern LLMs and “agentic coding,” where prompts/specs resemble high-level declarative descriptions.
  • Some see LLMs as a rough realization of this; others object that today’s LLMs are non-deterministic and error-prone, making the analogy weak or premature.
  • On AI history:
    • Lisp’s role in classical, symbolic AI (knowledge representation, reasoning, genetic programming) is highlighted.
    • With the shift to numerical deep learning, neural nets moved toward C/CUDA plus Python; Lisp didn’t disappear but stopped being central.
    • There is speculation that a modern “Lisp for neural nets” could be powerful if paired with GPU libraries.

Other Lisp Dialects and Anecdotes

  • Commenters mention enjoyable experiences with Scheme variants (CHICKEN, Chez), Common Lisp tooling, and babashka as a lightweight on-ramp.
  • A salary-survey tangent notes very high reported pay for Clojure developers but is widely dismissed as likely statistically insignificant.