There are no Upsides to Object Oriented Programming

A story about blind acceptance of induced complexity

Once upon a time I was a Computer Science student just starting his first classes. Among the mandatory topics were C++ programming and Fundamental Logic. Those two courses introduced me to a curious dichotomy that would repeat itself time and time again in the academic setting: while one professor proceeded to teach us the principles of Object Oriented Programming justified as the industry standard for big, serious projects, on the other side his/her colleague would explain us that those were outdated techniques rendered obsolete by more modern approaches to programming.

This was a recurring theme in almost every year: Programming versus Logics, Software Engineering versus Theoretical CS, Compilers vs Emerging Programming Paradigms.

About this, I was mostly confused. Regardless of the take on the issue, professors would give cryptic answers to requests of clarification: there are different opinions on the matter, the general consensus is shifting, some practices are not considered good anymore.

Being mandatory courses, I studied everything with an open mindset; I learned and understood OOP principles and correlated software design patterns, I did my homework an passed the exams. Then, a few months after my bachelor’s graduation, an occasion came to put those to practice as I started working on a semi-serious Android app.

Revelation and Horror

At the time the only approachable option for Android development was Java, which is of course an heavily Object Oriented programming language. As the code size grew I started to organize my work in classes: Managers, Factories, Subtyping and the likes. About four thousand of lines of code in and I was tangled in a web of dependencies and relations that I just could not free myself from.

After a couple of months a staggering realization hit me: there is no way to make this better; I have to fundamentally change my approach. I need functions, not objects; modules, not classes.

While I was trying to wrap my head around the problem the project came to an halt (probably for the best). I had however learned a great deal from it: peeking into the abyss of Object Oriented Programming, I understood why every programmer in the world is shifting away from it.

There is No Gray Area

Fast forward a few years, a CS Master Degree and some field experience later, and I’m here. My beliefs on OOP have only consolidated, to the point that I would refuse any job offer including it up front. Not only that, it’s quite evident I’m not alone.

There are less and less programming languages that provide an OOP option among the newly created ones. Rust, Go, Elixir, Elm, they all openly declare no class support. Those that do are successful because of other additions, like closures or parametric polymorphism.

Whenever the issue is brought up online, most opinions are polarized towards leaving OOP for good, with articles and blogs that argue for more modern alternatives.

Sadly, there is still remaining groups of developers insisting that the Object Oriented Paradigm holds some good sides for those that use it correctly. This is a delusion, and one that damages its supporters the most. There is no room for debate: the only good OOP language is a dead OOP language.