Always read older stuff from Carmack remembering the context. He made a name for himself getting 3D games to run on slow hardware. The standard advice of write for clarity first, make sure algorithms have reasonable runtimes, and look at profiler data if it's slow is all you need 99% of the time.
I find the inlined style can actually improve clarity.
A lot of code written toward the "uncle bob" style where you maximize the number of functions has fantastic local clarity, you can see exactly what the code you are looking at is doing; but atrocious global clarity, where it's nearly impossible to figure out what the system does on a larger scale.
Inlining can help with that, local clarity deteriorates a bit, but global clarity typically improves by reducing the number of indirections. The code does indeed also tend to get faster, as it's much easier to identify and remove redundant code when you have it all in front of you. ... but this also improves the clarity of the code!
You can of course go too far, in either direction, but my sense is that we're often leaning much too far toward short isolated functions now than is optimal.
One thing that's nice about functions is that they force the associated block of code to be named, and for state that is specific to the function to be clearly separate from external state (closures aside). It would be good to be able to retain those advantages even in linear code that nevertheless has clear boundaries between different parts of it that would be nice to enforce or at least highlight, but without losing the readability of sequential execution.
To some extent you can have that in languages that let you create a named lambda with explicit captures and immediately invoke it, e.g. in C++:
int g;
void doThisAndThat(int a, int b, int c) {
doThis: auto x = [&a, &b] {
...
}();
doThat: [&g, &c, &x] {
...
}();
}
The syntax makes it kind of an eyesore though. Would be nice to have something specifically designed for this purpose.
And before that, 2D games (side-scrolling platformers were not a thing on PC hardware until Carmack did it, iirc). I think his main thing is balancing clarity - what happens when and in what order - with maintainability.
Compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic (the complexity in video games is in performance optimization), but whose developers tend to add many layers of abstraction and indirection, so the core business process is obfuscated, or there's a billion non-functional side activities also being applied (logging, analytics, etc), again obfuscating the core functionality.
It's fun to go back to more elementary programming things, in e.g. Advent of Code challenges or indeed, game development.
"compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic"
Maybe this was true 20 years ago, but I do not think this is true today. Game code of some games is almost as complex as enterprise software or even more complex in some cases (think of grand strategy games like Civilization or Paradox games). The difference is that it still needs to be performant, so the evolutionary force just kills programmers and companies creating unperformant abstractions. In my opinion game programming is just harder than enterprise programming if we speak about complex games. (I have done both). The only thing which is easier in game programming is that it is a bit easier to
see clearly in terms of 'business requirements', and also it is more meritocratic (you can start a game company anywhere on the globe, no need to be at business centers.) And of course game programming is more fun, so programmers do the harder job even for less money.
For people who think game programming is less complex than enterprise software, I suggest the CharacterMovementComponent class in unreal engine which is the logic of movement of characters (people) in a networked game environment... With multiple thousand lines of code in just the header is not uncommon in unreal. And this is not complex because of optimization mostly. This is very complex and messy logic. Of course we can argue that networking and physics could be done in a simple naive way, which would be unacceptable in terms of latency and throughput, so all in all complexity is because of optimization after all. But it is not the 'fun' elegant kind of optimization, it is close to messy enterprise software in some sense in my opinion.
I have heard modern game development compared to OS development in terms of complexity and I think that comparison is quite apt; especially when the game involves intricate graphics and complicated networking involving multiple time scales as you say.
> And before that, 2D games (side-scrolling platformers were not a thing on PC hardware until Carmack did it, iirc). I think his main thing is balancing clarity - what happens when and in what order - with maintainability.
Smooth side-scrollers did exist on the PC before Keen (An early one would be the PC port of Defender). Moon Patrol even had jumping in the early '80s.
Furthermore other contemporaries of Carmack were making full-fledged side-scrolling platformers in ways different from how Keen did it (there were many platformers released in 1990). They all involved various limitations on level design (as did what Keen used), but I don't believe any of them allowed both X and Y scrolling like the Keen games did.
I agree with this in general, but his essay on functional programming in C++ (linked at the top of the page) is phenomenal and is fantastic general advice when working in any non-functional language.
