Object-Oriented Programming is The Biggest Mistake of Computer Science

C++ and Java probably are some of the worst mistakes of computer science. Both have been heavily criticized by Alan Kay, the creator of OOP himself, and many other prominent computer scientists. Yet C++ and Java paved the way for the most notorious programming paradigm — the modern OOP.

Its popularity is very unfortunate, it has caused tremendous damage to the modern economy, causing indirect losses of trillions upon trillions of dollars. Thousands of human lives have been lost as a result of OOP. There’s no industry that went untouched by the latent OO crisis, unfolding right before our eyes for the past three decades.

Why is OOP so dangerous? Let’s find out.Imagine taking your family out for a ride on a beautiful Sunday afternoon. It is nice and sunny outside. All of you enter the car, and you take the exact same highway that you’ve already driven on a million times.

Yet this time something is different — the car keeps accelerating uncontrollably, even when you release the gas pedal. Brakes aren’t working either, it seems they’ve lost their power. In a desperate attempt to save the situation, you pull the emergency brake. This leaves a 150-feet long skid mark on the road before your car runs into an embankment on the side of the road.

Sounds like a nightmare? Yet this is exactly what has happened to Jean Bookout in September, 2007 while she was driving her Toyota Camry. This wasn’t the only such incident. It was one of the many incidents related to the so-called “unintended acceleration”, which has plagued Toyota cars for well over a decade, causing close to 100 deaths. The car manufacturer was quick to point fingers at things like “sticky pedals”, driver error, and even floor mats. Yet some experts have long suspected that faulty software might have been at play.

To help with the problem, software experts from NASA have been enlisted, to find nothing. Only a few years later, during the investigation of the Bookout incident, the real culprit was found by another team of software experts. They’ve spent nearly 18 months digging through Toyota code. They’ve described the Toyota codebase as “spaghetti code” — a programmer lingo for tangled mess of code.

The software experts have demonstrated more than 10 million ways for the Toyota software to cause unintended acceleration. Eventually, Toyota was forced to recall more than 9 million cars, and paid over $3 billion in settlement fees and fines.

Is spaghetti code a problem?

Photo by Andrea Piacquadio from Pexels

100 human lives taken by some software fault is way too many. What makes this really scary is that the problem with Toyota code isn’t unique.

Two Boeing 737 Max airplanes have crashed, causing 346 deaths, and more than 60 billion dollars in damage. All because of a software bug, with 100% certainty caused by spaghetti code.

Spaghetti code plagues way too many codebases worldwide. On-board airplane computers, medical equipment, code running on nuclear power plants.

Program code isn’t as much written for the machines, as it is written for fellow humans. As Martin Fowler has said, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

If the code doesn’t run, then it’s broken. Yet if people can’t understand the code, then it will be broken. Soon.

Let’s take a quick detour, and talk about the human brain. The human brain is the most powerful machine in the world. However, it comes with its own limitations. Our working memory is limited, the human brain can only think about 5 things at a time. This means, that program code should be written in a way that doesn’t overwhelm the human brain.

Spaghetti code makes it impossible for the human brain to understand the codebase. This has far-reaching consequences — it is impossible to see if some change will break something else. Exhaustive tests for flaws become impossible. No one can even be sure if such a system is working correctly. And if it does work, why does it even work?

What causes spaghetti code?

Photo by Craig Adderley from Pexels

Why does code become spaghetti code over time? Because of entropy — everything in the universe eventually becomes disorganized, chaotic. Just like cables will eventually become tangled, our code eventually will become a tangled mess. Unless sufficient constraints are put in place.

Why do we have speed limits on the roads? Yes, some people will always hate them, but they prevent us from crashing to death. Why do we have markings on the road? To prevent people from going the wrong way, to prevent accidents.

A similar approach would totally make sense when programming. Such constraints should not be left to the human programmer to put in place. They should be enforced automatically, by tooling, or ideally by the programming paradigm itself.

Why is OOP the root of all evil?

Photo by NeONBRAND on Unsplash

How can we enforce sufficient constraints to prevent the code from turning into spaghetti? Two options — manually, or automatically. Manual approach is error-prone, humans will always make errors. Therefore, it is logical for such constraints to be automatically enforced.

Unfortunately, OOP is not the solution we’ve all been looking for. It provides no constraints to help with the problem of code entanglement. One can become proficient in various OOP best practices, like Dependency Injection, test-driven Development, Domain-Driven Design, and others (which do help). However, none of that is enforced by the programming paradigm itself (and no such tooling exists that would enforce the best practices).

None of the built-in OOP features help with preventing spaghetti code — encapsulation simply hides and scatters state across the program, which only makes things worse. Inheritance adds even more confusion. OOP polymorphism once again makes things even more confusing — there are no benefits in not knowing what exact execution path the program is going to take at runtime. Especially when multiple levels of inheritance are involved.

OOP further exacerbates the spaghetti code problem

The lack of proper constraints (to prevent code from becoming a tangled mess) isn’t the only drawback of OOP.

In most object-oriented languages, everything by default is shared by reference. Effectively turning a program into one huge blob of global state. This goes in direct conflict with the original idea of OOP. Alan Kay, the creator of OOP had a background in biology. He had an idea for a language (Simula), that would allow writing computer programs in a way that resembles biological cells. He wanted to have independent programs (cells) communicate by sending messages to each other. The state of the independent programs would never be shared with the outside world (encapsulation).

Alan Kay never intended for the “cells” to reach directly into the internals of other cells to make changes. Yet this is exactly what happens in modern OOP, since in modern OOP, by default, everything is shared by reference. This also means that regressions become inevitable. Changing one part of the program will often break things somewhere else (which is much less common with other programming paradigms, like Functional Programming).

We can clearly see that modern OOP is fundamentally flawed. It is the “monster” that will torture you every day at work. And it will also haunt you at night.

Let’s talk about predictability

Photo by samsommer on Unsplash

Spaghetti code is a big problem. And Object-Oriented code is especially prone to spaghettification.

Spaghetti code makes software unmaintainable. Yet it is only a part of the problem. We also want software to be reliable. But that is not enough, software (or any other system for that matter) is expected to be predictable.

A user of any system should have the same predictable experience, no matter what. Pressing the car accelerator pedal should always result in the car speeding up. Pressing the brakes should always result in the car slowing down. In computer science lingo, we expect the car to be deterministic.

It is highly undesirable for the car to exhibit random behaviors, like the accelerator failing to accelerate, or the brakes failing to brake (the Toyota problem). Even if such issues occur only once in a trillion times.

Yet the majority of software engineers have the mindset of “the software should be good enough for our customers to keep using it”. Can’t we really do any better than that? Sure, we can, and we should do better than that! The best place to start is to address the nondeterminism of our programs.

Nondeterminism 101

In computer science, a nondeterministic algorithm is an algorithm that, even for the same input, can exhibit different behaviors on different runs, as opposed to a deterministic algorithm.

— Wikipedia article on Nondeterministic Algorithms