John Carmack on inlined code (2014)

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.