A Tour of the Lisps
Lisp and its many dialects — from Common Lisp, Scheme and Racket to Clojure and smaller variants like Gauche, Guile and Fennel — are examined as powerful yet niche alternatives to mainstream languages. Commenters weigh the elegance of homoiconic syntax, macros, REPL-driven development and interactive debugging against real-world barriers such as ecosystem fragmentation, non-Algol syntax, tooling quirks, JVM trade‑offs and the risk of “wizard-only” DSLs. Several contributors argue that Lisps can be highly pragmatic in areas like web backends, scripting and GUIs, but that social inertia, documentation quality and hiring dynamics matter more than language design in limiting wider adoption.
Popularity and adoption of Lisps
- Many commenters are long‑time intrigued by Lisp but stuck in mainstream languages (Python, Java, JS) due to inertia, libraries, and organizational lock‑in.
- Popularity is framed as largely historical and social, not about “better design”: Unix/C/C++/Java/Python won early and built ecosystems; Lisps never got a killer app plus vendor backing at scale.
- Some argue business prefers “bureaucrat” languages that are easy for average developers, with familiar syntax and constrained power, over “wizard” languages like Lisps.
Strengths, weaknesses, and “wizard” culture
- Praised qualities: minimal, uniform syntax; macros/DSLs; REPL‑driven interactive development; strong debuggability; expressiveness; ability to embed and extend languages.
- Critiques: the flexibility can be a “footgun” – one “wizard” can create unreadable DSLs; quasiquote/unquote and macro systems are seen as a major learning cliff.
- Counter‑argument: most real Lisp code is straightforward, not macro‑heavy; DSLs and patterns are learnable, and bad complexity happens in any language.
Recursion, immutability, and performance
- Scheme and some FP styles emphasize recursion, which some find elegant and aligned with immutability; others find it hard to read and poorly matched to modern hardware (branching, lack of SIMD).
- Common Lisp is seen as more pragmatic: many powerful iteration constructs; recursion mainly for naturally recursive data (trees).
- Tail‑call optimization is a recurring topic: Schemes lean on it; CL does not require it; JVM blocks general TCO, but Clojure’s
loop/recuris viewed as a pragmatic substitute.
Implementations and ecosystems
- Clojure: strong enthusiasm for its design, immutability, concurrency, and access to the JVM ecosystem. Downsides noted: JVM startup, stack traces, limited tail calls, and platform constraints (e.g., Lambda costs). Native variants (GraalVM, babashka, jank) are discussed.
- Common Lisp: powerful, mature, fast compilers and debuggers, but criticized for inconsistent standard library naming, dated tooling quirks, and ecosystem oddities.
- Scheme world: fragmentation and SRFI/R7RS confusion seen as a major barrier. Guile praised for ambition but criticized for documentation/UX; Gauche, Chicken, Chez, Gambit, Racket, Kawa, Gauche, Janet, Fennel, Hy, femtolisp all get shout‑outs with mixed “fun but niche” assessments.
- Racket divides opinion: some see it as academic/kid‑oriented; others argue it’s highly pragmatic and performant, especially with Chez, strong tooling, macros, and sublanguage support.
Tooling, REPL, and debugging
- Lisp debuggers and REPL‑driven development are repeatedly lauded as qualitatively better than print debugging or traditional debuggers, especially for interactive modification of live systems.
- Some note practical issues in locked‑down production environments where attaching a live REPL is hard.
Jobs and career aspects
- Lisp jobs are rare but exist (especially Clojure; some CL). Suggestions: watch HN “Who’s Hiring”, niche subreddits/Slack, “awesome Lisp companies” lists, and, importantly, create Lisp opportunities by introducing it where feasible.
- Some claim Lisp/F#/Haskell experience is a positive hiring signal; others warn niche‑language careers usually mean fewer, not higher‑paying, roles.