John Carmack on inlined code (2014)

Original Article ↗ Hacker News Discussion ↗

Inline, highly sequential code can make complex systems faster and easier to reason about, but it clashes with common advice to abstract aggressively, de-duplicate logic, and slice everything into tiny functions. Commenters contrast performance-oriented, state-heavy game and embedded loops with more modular “enterprise” code, arguing over when duplication is safer than indirection, how much to trust principles like DRY or YAGNI, and why experience often leads developers to favor readability and locality of behavior over speculative reuse. Several suggest that pure functional techniques and better tooling for testing and constraining state may scale human comprehension better than current object‑heavy or AI‑generated styles.

Inlining vs Abstraction

  • Many commenters echo the article’s point: inlining impure, stateful logic can expose hidden dependencies and timing, but overdoing it leads to giant, unreadable functions.
  • Others strongly prefer small, named functions for “global clarity”: the top-level code reads as a sequence of well‑named steps instead of a wall of logic.
  • Several distinguish true abstractions (new semantic levels) from mere indirections (just another place to jump), arguing the latter often age poorly.

DRY, YAGNI, and Over‑Engineering

  • A recurring theme: rigid application of DRY, SOLID, “clean code” can create brittle, over‑abstracted systems.
  • Heuristics offered:
    • “Twice is fine, third time maybe abstract.”
    • Prefer a little duplication over new dependencies/indirections.
    • YAGNI should default: don’t generalize until you have at least 2–3 real call sites.
  • Others push back, noting that duplicated code can hide bugs when only some copies are fixed.

Functional Style and Purity

  • The article’s later endorsement of more functional style is highlighted: pure functions reduce the very state‑mutation hazards that motivate inlining.
  • Debate over what “pure FP” really entails; some emphasize referential transparency and segregation of IO, others see this as academic or hard to apply in non‑FP languages.
  • There's tension between seeing FP as transformative vs. “just another tool” with significant tradeoffs and learning curve.

Readability, Human Limits, and Developer Maturity

  • Several describe a career arc:
    • Early “simplest thing that works.”
    • Mid‑career over‑abstraction and architecture obsession.
    • Later preference for boring tech, minimal speculative reuse, and clearer code for “low‑effort mode” reading.
  • Different minds prefer different styles: some want every gritty detail in one place; others rely on abstractions to filter noise. Mixed teams need compromise.

Testing and Unit Boundaries

  • Inlined or nested functions reduce the surface area that can be called incorrectly, but also reduce direct unit‑testability of small pieces.
  • Some argue the true “unit” is the public API; internals should be tested via that. Others like fine‑grained tests on small helpers, especially for tricky edge cases.

Performance, Control Loops, and Context

  • The original context of tight control loops and latency‑sensitive game/embedded code matters: in those domains, inlining, deterministic control flow, and minimized branches are often worth extra complexity.
  • Multiple voices caution that most application and backend code is not in that regime; for it, clarity and maintainability should dominate.