# John Carmack Reopens an Old Argument for Inline Code as a Reliability Tool
*Event date: 2024-10-06*
By IO Digest Desk
A decade-old post recirculating on October 6, 2024 brought renewed attention to one of John Carmack’s more unusual software design arguments: that in some systems, pulling logic out of deep call stacks and laying it out inline can improve understanding, reliability, and even product outcomes. The source material is a 2014 comment by Carmack reflecting on an email he originally sent in 2007, and it reads less like a style preference than a case study in how real-time software goes wrong.
Carmack’s core point is narrower than the shorthand version often attached to it. He is not arguing that avoiding function calls is inherently a performance optimization. Instead, he says the practical value of inlining is that it forces developers to confront state mutation and execution order directly. When code that runs every frame is scattered across layers of calls, overloaded operators, and implicit behavior, large parts of the system can remain mentally invisible even when they are central to performance and correctness.
The essay ties that argument to software he knew firsthand. Carmack describes discussions about highly reliable aerospace systems, including an anecdote about Saab Gripen flight software that reportedly disallowed subroutine calls and backward branches apart from the main loop. He does not present that model as something the whole industry should copy. In fact, he explicitly warns that much of aerospace process would be self-defeating in mainstream software. What he takes from it is a narrower lesson: simplifying control flow can make testing and reasoning easier.
He then describes applying the idea to Armadillo rocket flight-control code. After inlining subroutines inside a main tick function, he says he did not uncover a single catastrophic hidden bug, but he did find variables being set multiple times, suspicious control-flow patterns, and opportunities to make the final code smaller and cleaner. That is the theme running through the entire piece. Inline layout is valuable because it reveals what the system is actually doing, especially in code that executes continuously and where a misplaced operation can create latency or reliability problems that are difficult to spot from abstractions alone.
Carmack adds an important update from the vantage point of 2014. Over time, he says, he became more bullish on pure functional programming, even in C and C++. In that revised view, the real enemy is not the function call itself but unexpected dependency and mutation of state. Functional design addresses that more directly. Even so, he still argues that if a program is going to mutate state heavily, exposing those changes inline can force engineers to confront the “full horror” of what the code is doing, then refactor pieces into pure functions only after the structure becomes clear.
That perspective is reinforced by one concrete near miss. Carmack says that while working on the Doom 3 BFG Edition release, the sort of off-by-one-frame input-sampling latency he had warned about nearly shipped. For a programmer long associated with responsiveness and engine performance, the episode is presented as evidence that hidden sequencing errors are not theoretical. They survive experience, abstractions, and good intentions.
The reason the piece still resonates is that it speaks to a modern tension in software engineering. Developers want modularity, expressive language features, and reusable components. Carmack’s essay does not dismiss those goals. It asks what happens when those tools make the most important path through a program harder to see. In game loops, control systems, and other timing-sensitive environments, readability may sometimes mean fewer indirections rather than more.
