Why "Structure and Interpretation of Computer Programs" matters (2011)

Original Article ↗ Hacker News Discussion ↗

Perceived purpose and value of SICP

  • Many see SICP as a foundational text on how computation and abstractions work (procedures, data, interpreters, evaluators, types as tags), not an algorithms reference.
  • Readers report long‑term changes in how they think about language constructs, problem decomposition, and DSLs.
  • Some argue the main gains are conceptual (e.g., understanding interpreters, OO from first principles), which later transfer well to other languages.
  • Others think its influence has encouraged over‑abstraction and inefficient software.

Suitability for beginners vs experienced programmers

  • Several commenters read it after years of professional work and found it eye‑opening, especially if their background was mainly in mainstream imperative/OOP languages.
  • Others found it redundant with a solid CS education or prior experience with interpreters/FP.
  • Some say it’s a poor first book: too mathy, abstract, or “quixotic,” and better as a second‑pass or capstone text.
  • A few report bouncing off early chapters and never returning; a minority say it nearly put them off programming entirely.

Scheme/Lisp vs mainstream languages (esp. JavaScript)

  • There’s extensive counterfactual debate about “what if the web had chosen Scheme instead of JavaScript.”
    • Pro‑Scheme side: simpler core, proper tail calls, call/cc, macros, clearer semantics.
    • Skeptical side: browser language success depends on syntax familiarity, ecosystem, and corporate needs; Lisp syntax would likely have limited adoption and not fixed JS’s design‑in‑a‑rush problems.
  • Discussion of Erlang vs Elixir is used as an example: same VM, but more familiar syntax and tooling helped Elixir spread.

Syntax, cognition, and structural editing

  • Long argument over whether curly‑brace / Algol‑style syntax is “innate” or just historical accident.
  • Some stress redundancy and varied delimiters as helpful for human error correction; others value Lisp’s uniformity and ease of macro‑based extension.
  • Parentheses complaints are challenged with structural editors (paredit, smartparens, parinfer) and IDE support, but critics still find S‑expressions visually noisy or cognitively heavy.

Lisp in practice: power vs maintainability

  • Praised features: REPL‑driven development, macros, interactive introspection, DSLs, stable standards, named arguments and documentation in Common Lisp.
  • Criticisms: fragmentation, small ecosystems, “everyone invents their own abstractions,” divergent styles, making large projects hard to maintain and onboard to.
  • Some argue other languages have absorbed many Lisp innovations (GC, higher‑order functions) except S‑expression syntax, which remains niche.

Pedagogy and course design

  • Conflicting TA reports:
    • One camp says Scheme’s small, uniform core lets courses spend minimal time on syntax and focus on ideas; students handle it well.
    • Another camp says “everything looks the same” causes persistent confusion; abstractions are taught before students have concrete needs for them.
  • Debate over whether intro courses should prioritize conceptual depth (SICP, Scheme) or more “extroverted” projects tied to real systems (Python, robots, web).

Related works and resources

  • Comparisons to “Paradigms of Artificial Intelligence Programming” (PAIP): SICP is more academic and language‑agnostic; PAIP is more Common Lisp‑ and GOFAI‑focused, with more practical software design.
  • Multiple links mentioned: new official SICP HTML site, third‑party EPUB, JS and Python adaptations, and classic lecture videos.