4 ms·

John Carmack on this topic: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... And

John Carmack on this topic: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... And I easily agree 100% with him having tried both approaches in bigger projects.

Groxx 8y ago
There's a bit of a fuzzy edge in there, where he favors "inline, don't break up artificially" but also "more pure functional code". Breaking pure logic out of a large, otherwise mixed-purity func gives you those stronger purity guarantees / separations, which seems to favor more funcs. But he's also huge on "don't fight the compiler" and static analysis, all of which are aided by strictly pure funcs, so it seems in-character.
- jungler 8y ago
  That's because he comes from a domain where mutable state is a necessary thing in making the different parts of game logic feed into each other. It is the focus of debugging. The actual computations around what changed can be pure, but turning them into a concurrently operating loop is done most effectively with a static sequencing(and hence, straightline imperative). Or in other terms, he is using a different strategy for different parts of the codebase. At the top level it's imperative, but when you drill down into the callstack, it isn't. A lot of folks work on request-response systems all day, and in those, the necessary state changes tend to be once-per-request and wrapped in transaction or session logic. So it's a lot less crucial to have this kind of strategy for debugging purposes.
shoo 8y ago
The anecdote Carmack shares from aviation is interesting: >Indeed, if memory serves (it's been a while since I read about this)... > >The fly-by-wire flight software for the Saab Gripen (a lightweight >fighter) went a step further. It disallowed both subroutine calls and >backward branches, except for the one at the bottom of the main loop. >Control flow went forward only. Sometimes one piece of code had to leave >a note for a later piece telling it what to do, but this worked out well >for testing: all data was allocated statically, and monitoring those >variables gave a clear picture of most everything the software was doing. >The software did only the bare essentials, and of course, they were >serious about thorough ground testing. > >No bug has ever been found in the "released for flight" versions of that >code. > > Henry Spencer
- FlyMoreRockets 8y ago
  Henry Spencer is one of the internet's greatest treasures.

Groxx 8y ago

There's a bit of a fuzzy edge in there, where he favors "inline, don't break up artificially" but also "more pure functional code". Breaking pure logic out of a large, otherwise mixed-purity func gives you those stronger purity guarantees / separations, which seems to favor more funcs. But he's also huge on "don't fight the compiler" and static analysis, all of which are aided by strictly pure funcs, so it seems in-character.

jungler 8y ago
That's because he comes from a domain where mutable state is a necessary thing in making the different parts of game logic feed into each other. It is the focus of debugging. The actual computations around what changed can be pure, but turning them into a concurrently operating loop is done most effectively with a static sequencing(and hence, straightline imperative). Or in other terms, he is using a different strategy for different parts of the codebase. At the top level it's imperative, but when you drill down into the callstack, it isn't. A lot of folks work on request-response systems all day, and in those, the necessary state changes tend to be once-per-request and wrapped in transaction or session logic. So it's a lot less crucial to have this kind of strategy for debugging purposes.

shoo 8y ago

The anecdote Carmack shares from aviation is interesting: >Indeed, if memory serves (it's been a while since I read about this)... > >The fly-by-wire flight software for the Saab Gripen (a lightweight >fighter) went a step further. It disallowed both subroutine calls and >backward branches, except for the one at the bottom of the main loop. >Control flow went forward only. Sometimes one piece of code had to leave >a note for a later piece telling it what to do, but this worked out well >for testing: all data was allocated statically, and monitoring those >variables gave a clear picture of most everything the software was doing. >The software did only the bare essentials, and of course, they were >serious about thorough ground testing. > >No bug has ever been found in the "released for flight" versions of that >code. > > Henry Spencer

FlyMoreRockets 8y ago
Henry Spencer is one of the internet's greatest treasures.