Object-oriented code has its merits and when it was first established, it was designed with the goal of simplifying a lot of the nuances of procedural code. Unfortunately, this goal expanded and now we see what C++ has become, with over-specified features and falling into the same traps that languages following the procedural paradigm fell into.

The act of programming in either paradigm is not the reason why coders have become worse over time, but object-oriented programming I feel is certainly a factor when it is the primary paradigm used in academia. Upon discovering Jonathon Blow and Casey Muratori through his Handmade Hero series, it became clear that some features of object-oriented programming just didn't make sense.

Let's first talk about the way people program and why object-oriented code tends to be slower than procedural programming. Remember, it is not the paradigm itself that's the problem, the problem is that people in coding communities take the features of the paradigm for granted and overuse it.

Just take arrays. There are two array methods that exist in programming, called Array of Structures (AOS) and Structure of Arrays (SOA). Generally, AOS is faster than SOA.

Why is it faster?

One Word: Aggregation. CPU's perform fastest when dealing with groups of memory bundled together than memory allocated on the heap. The structure of arrays approach almost always ensures everything you allocate in memory is allocated on the stack and performance is drastically increased. This approach is also fundamentally easier to manage as we can access an index whenever we wish instead of iterating over an entire array to find items we need.

There are multiple sources online that explain the SOA vs AOS approach much better than I could.

One of the other reasons to use the procedural approach over object-oriented is in its simplicity. Code, especially for large projects, will get increasingly more complicated. Simplifying as much of your code as feasibly possible will make it more approachable for people not familiar with the codebase. Hierarchies sound good in practice, but ultimately is doomed to failure.

Don't get me started on UI frameworks. I have tried to like other frameworks that provide a cross-platform solution, such as GTK or WxWidgets, but neither grabbed me. They are too complicated and leave much to be desired. Web technology is even worse, as now you have to learn more than one language to build something useful.

Dear IMGUI, on the other hand, is extremely approachable because it is extremely simple.

if (ImGui.Button("Click me!"))
    // do something with button on click

No, dear imgui is not ideal for the average user, but it's still better than the indominable infestation of retained-mode user interfaces for the programmer.

Importantly, when coding in either paradigm, it is always a good idea to think in terms of the computer and manage your memory as much as possible towards winning over the CPU rather than deliberately making it churn to make our code look clean. I would rather look at code that functions and performs properly than clean code that is x3 slower than the former.

There is also a feature of object-oriented coding I personally really do not like.


Exceptions make me cringe. It is a way of handling errors where you assume a certain part of your code might go wrong and you don't correctly handle that case using a condition. Checking if a file exists prior to opening a stream is something that you shouldn't have to do if the underlying API forces you to capture this in an Exception instead. It's completely unnecessary.

The same goes for Null exceptions. I already know the computer doesn't like reading null pointers or references that are invalid in memory. Just tell me and I will fix it, instead of forcing me to check if your API throws a NullException.

What's worse is dealing with exceptions when mobile devices hide this information from the user, making both the user and the developer guess what the problem was in order to fix the issue. Most users probably don't even know how to turn on Developer Tools to get Exception responses.

Future Disclaimer

When I start my tutorials on building a video game using Twinspire using procedural-style programming, I will also be using a technology I used since the beginning of my self-taught career. This is C# and WinForms technology. At the time, I was still learning the ropes of programming and object-oriented programming was what I first got into.

WinForms is also the technology I go to when I need something quick and need a user interface that I can whip up in an hour and start using without any problems. It is the environment I am generally most confident in, but it is against the very points I have made above about procedural style programming.

Sometimes taking shortcuts is a necessary evil, and in this case I will be using WinForms technology to build the editor required to create the content for the video game I intend to build and share with you.

See you in the next post, when I begin discussing and laying out the roadmap for future tutorials and content to come.

Developer at home, customer services at work. In my free-time, I enjoy writing and coding.