I think there are a number of attitudes engendered by the nature of doing game programming, especially low-level engine programming, for a long time. Game progr

I think there are a number of attitudes engendered by the nature of doing game programming, especially low-level engine programming, for a long time. Game programmers aren't unaware of the rest of the programming universe, but the risks mean that they tend to indulge only one or two new ideas at a time for production code. One such attitude is that the code is disposable - you cut down the buglist until the game ships, and then boom, new project, greenfield code. (or sometimes, same engine, but you can go in and gut it until it fits the new design) Another is that your primary goal as the engine programmer is to push out data as quickly as possible - more things onscreen, with more detail and more effects; if you aren't doing this, then you're probably spending your technical budget to explore a completely new technology instead. Higher-level abstractions are weeded out if they aren't supplementing these goals. This means that game programmers see the code as something that you scrub out and redo over and over in order to match the new data model you're optimizing against(which necessarily changes as hardware and design goals changes). You're gonna throw the code out tomorrow, so there's no sense in spending a lot of "thinking and theorizing" time on it to reach artificial ideals. You have a clear destination to reach instead. The ideal provided as an alternative is to reduce your coding to an efficient, even boring process that consistently gets you towards a working solution that can be optimized later, even whilst you're keeling over from crunch. Game coders don't optimize everything right off the bat because they need real-world data for the test case, so the engine only really gets performance tuned in the later stages of a project as more of the content is completed. The early days are often more important because they're done with the understanding that all the maintenance work needed to ship must be done before ship, so you can only take on technical debt on a feature if it means the feature will never be touched again; otherwise the only reason to do it is to hit one of those stupid publisher milestones that requires a feature to be in place prematurely. Another issue is that not all abstractions are available. Stuff reliant on GC is generally out, because control over memory allocation is a must. Stuff that bloats memory usage, also generally out. Stuff that leads to unpredictable execution times(e.g. lazy evaluation) is dismissed immediately. Imperative style is still the groundwork for game code, if only because simulated worlds encourage massive amounts of mutability and global state. So at the same time there's a tunnel vision that comes out of this approach. Not every game needs that level of optimization, and not every optimization is a matter of peering at the hardware and seeing what form the data needs to be in for go-fastness(which is 90% of the Acton slides). But because the programmer also can't predict "how much" performance is enough, they tend to estimate conservatively, defer to C++ and to their hardware once more, and just pull out the old bag of tricks to make it go. And then ship at 30hz when it turns out that the estimate still wasn't good enough for 60.