Ask HN: 30y After 'On Lisp', PAIP etc., Is Lisp Still "Beating the Averages"?

Hacker News Discussion ↗

Lisp’s reputation as a “power language” is re‑examined through comparisons with modern ecosystems like Python, Java, Rust, and Go, and real-world experiences from teams using Common Lisp, Clojure and related dialects in production (finance, trading, infrastructure, web systems). Commenters highlight Lisp’s strengths—REPL‑driven development, macros, DSLs, live code reloading, and highly productive solo or small‑team work—while noting trade‑offs such as weaker library ecosystems, hiring difficulty, and the advantages of static typing and conventional structure in large organizations. The emerging consensus is that Lisp still “beats the averages” in certain complex, fast‑changing domains and for developers who invest in its tooling, but that language choice today is more about fit with the problem, team, and ecosystem than about any one language sitting at the top of a universal power curve.

Production-ready Lisps & Real-world Use

  • Common Lisp, Clojure, ClojureScript, Racket, Scheme, LFE, Janet, Emacs Lisp, and various custom dialects are reported in production.
  • Use cases mentioned: blockchain/smart-contract-like systems, financial streaming/realtime analytics, algorithmic trading, web publishing, tunnels and transport control, airline booking, aerospace, cybersecurity, and other backend services.
  • Some shops report tiny teams in CL delivering output that makes them look much larger to clients.

Productivity: REPL, Image-based Dev, Macros

  • Many argue Lisp’s REPL + image-based workflow is still a unique advantage: live modification of running systems, redefining functions without restart, tracing and debugging with resumable stack frames.
  • Comparisons say Python/Jupyter REPLs feel more like shells; Clojure/CL REPLs integrate tightly with editors and entire codebases.
  • Macros and homoiconicity are seen as key: easy DSLs, code generation, graph/DAG builders, autodiff, numeric DSLs; Julia is cited as a “lispy” example where macros saved thousands of LOC.
  • Others warn macros and heavy metaprogramming can hurt readability if overused; some style guides advise restraint.

Types, Structure, and Maintenance

  • Pro-static-typing voices stress that types and rigid structure help large teams, long-lived code, and onboarding; dynamic Lisps can feel like “unlabeled tubes” that require runtime probing.
  • Counterpoints: CL has optional but powerful types; Typed Racket, Coalton, and Clojure’s Spec/Malli add advanced constraints; REPL debugging can be faster than chasing static types.
  • Several note that design quality and developer skill dominate language choice for maintainability.

Ecosystem, Tooling, and Hiring

  • A recurring criticism: CL’s library ecosystem is thinner, less standardized, and less documented than Python/Java, which hurt past deployments (e.g., web rewrites).
  • Others say in regulated or niche domains, external libraries rarely fit well anyway, so writing your own in Lisp is fine.
  • Tooling debates: Emacs is loved by some and viewed as clunky by others; alternative integrations exist for VSCode, JetBrains, Vim/Neovim, etc.
  • Hiring is harder; Lisp tends to attract experienced, niche developers, which can be a strength (high ROI per hire) but limits team scaling.

“Beating the Averages” and When to Use Lisp

  • Supporters say Lisp still “beats the averages” for:
    • Greenfield, exploratory, and rapidly changing specs.
    • Complex domains where DSLs and live refactoring matter.
    • Small, high-skill teams optimizing feedback loops.
  • Skeptics argue:
    • Many Lisp ideas (GC, first-class functions, FP, REPLs) are now common elsewhere, reducing its relative advantage.
    • Popular software and big organizations mostly use other languages; ecosystems and hiring often outweigh language power.
  • Several commenters conclude there’s no single “top of the power curve”: pick the language (or DSL in Lisp) that best fits your specific problem and constraints.