Low Level Thinking, High Level Programming

A few years ago, Vanity Fair called the 2000s "The Lost Decade" for Microsoft. Most of the reason for that name was financials and business decisions, but at the C++ and Beyond conference in 2011, Herb Sutter invoked Vanity Fair's expression to 

talk about the decisions that Microsoft had made going all-in on the .NET framework and largely stepping away from native cod

e . He said it was important to be focused again on low level programming, despite the fact that people coming up in the web and the .NET era thought mainly of abstraction. Herb claimed that native code was still relevant even for application level developers.

For people familiar with working in restricted resource environments not much has changed- but on the web and in a lot of application development, abstraction and patterns have been king. In games, there have been developers cramming as much as they can into as few registers as possible for a long time. This is partially because that's what was necessary, and partially because that freed up thinking and resources to deal with bigger more important problems. It's a kind of sokoban puzzle played by programmers hoping to squeeze just a few more milliseconds out of whatever it is they are making, or an exercise in minimalism where each piece has great importance.


Now we're in an era where games as a medium allow us to tell many diverse stories. We're not just making efficient machines any more, we are making art. That's incredible, and the democratization of tools has meant that so many more voices can contribute to what we play. In the process however, it's easy to forget how knowledge of the craft can facilitate creativity. Games are at a point where we are lucky to have diverse audiences and still be able to try new things, building upon the work of many before us. It's natural to look for higher level abstractions. It is empowering! But, as developers we should still remember the lessons of "The Lost Decade".

Emil Persson spoke at GDC in 2013 

about the nature of high level shading languages and how as we get further from the hardware, it's easy to forget about what is actually happening under the hood. Falling into, "the compiler will handle it" or "resources are plentiful" means when things change at a lower level, we may not question what the implications are and instead convert knowledge into mysticism. The beauty of where we are at is that we can use the benefits of high level tools better if we still take the time to know the how and why that things work the way they do.

There will always be places for high and low level languages but no matter what type of tools you use, it will always be important to understand why and how things happen. The great thing about this is that it doesn't take very long to test. Trying out the different collections, iterators, operations or tools to see what is really happening and what each thing is good or bad at means that you will always know the right tool for the job. Be inquisitive and critical, then focus on what matters. Use low level understanding to be optimal and be able to focus on high level problems.

Jon, Lead Engineer


-Jon McElroy, Lead Engineer