The Evolution of Lisp (1993) [pdf]

Original Article ↗ Hacker News Discussion ↗

What Counts as “Lisp”?

  • Ongoing argument over whether “Lisp” is a single language, a tightly related family (Lisp 1.5 → Maclisp → CL, Emacs Lisp, etc.), or a broad family including Scheme, Clojure, Racket, Dylan, Julia.
  • Narrow view: Lisp is defined by McCarthy’s list-processor model: linked lists as core data, s-expressions for code and data, and an interpreter (eval) written in the language itself.
  • Broader view: Lisp is defined by homoiconicity, macros, code-as-data, and REPL-driven development; under this, Clojure and others clearly qualify.
  • Some argue taxonomy matters because marketing newer “Lisps” can mislead newcomers about what “Lisp” is (e.g., assuming all Lisps are purely functional or immutable).

Clojure, Racket, and Hosted Lisps

  • Dispute over whether Clojure is an “actual Lisp” or a separate “Clojure family,” due to choices like non-interned symbols, different cons/list behavior, no numeric tower, and heavy JVM integration.
  • Counterpoint: Clojure’s creator calls it a Lisp dialect; many see it as a legitimate, modern Lisp with pragmatic trade-offs (persistent data, hosted design).
  • Hosted nature (JVM, JS, .NET, Dart) is praised for leveraging existing ecosystems and enabling powerful cross-platform patterns, but criticized when core list operations aren’t uniform across variants.

REPLs, Condition Systems, and Interactivity

  • Some insist “real Lisp power” includes modifying running programs, restartable errors, and rich debugger/REPL integration—features strongly associated with Common Lisp and historical Lisp machines.
  • Others note Clojure has a powerful REPL and that full continuation/restart systems haven’t been a high-priority demand there; libraries can approximate CL-style condition systems.

Tooling and IDE Experience

  • One view: to “get” Lisp you need Emacs + SLIME/SLY-style workflow; without that, it’s just a funny syntax.
  • Others argue Emacs is not required; Racket, LispWorks, and other environments offer friendlier or more modern experiences, though cost and limitations are concerns.

Readability and Syntax Debates

  • Some call Lisp “non-readable”; others argue its uniform, minimal syntax is among the most readable once you’re used to it.
  • Advocates stress structural editing and live REPL evaluation as key to making Lisp code understandable; critics emphasize initial difficulty distinguishing special forms and control flow.
  • General sentiment: every major language has its own readability traps; Lisp’s are mostly about unfamiliarity and parentheses.

Practical Value and “Aha” Moments

  • Several say you won’t get a “Lisp Aha!” from algorithm snippets; the difference is in workflow: rapid, incremental, REPL-driven development and easy refactoring into many small functions.
  • Skeptics note that many canonical Lisp demos (macros, tiny DBs, language extensions) feel less compelling when comparable tools/libraries already exist in mainstream languages.
  • Proponents point to large real-world systems and long-lived projects in various Lisps as evidence that readability/maintainability are not inherently worse.

Learning Resources and Variants

  • Recommended resources include Common Lisp and Scheme textbooks, Racket’s documentation, Emacs Lisp manuals, PAIP, and various “build your own Lisp” or compiler projects.
  • Some praise Racket, Janet, Fennel, Emacs Lisp, and ClojureScript koans for beginner-friendly docs; others highlight Emacs itself as both a Lisp implementation and a rich learning environment.