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

Hacker News Discussion ↗

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.