Why Are So Many Developers Hating on Object-Oriented Programming?
Object-oriented programming: Some developers love it — but some hate it.
Object-Oriented Programming (OOP) is that long-standing programming paradigm — a coding style, a school of thought, a practice taught in schools — that preaches the importance of organizing your code into larger meaningful “objects” that model the parts of your problem. These handy objects bundle together all the necessary variables for describing each possible “state” of your model’s components — as well as all of the methods (subroutines or functions) necessary for changing each variable’s data.
This is supposed to match the way people actually think in the real world, arranging their code into meaningful chunks with relationships that are obvious and intuitive. You end up with different families of objects, all discretely interacting with each other and swapping messages about the state of their data or whatever changes should be made next.
But in practice, detractors claim, OOP doesn’t always work out this way.
The “haters” camp includes Ilya Suzdalnitski, a senior full-stack engineer who last month posted a 6,000-word essay dubbing OOP a “trillion-dollar disaster.” And it turns out he’s not the only one with strong feelings. After writing a follow-up essay, he found that “The two articles combined have been read about half a million times in about a month!”
So what’s the big beef? By making things more complex, “OOP fails at the only task it was intended to address,” Suzdalnitski argues. Object-oriented programs instead end up with variables and their mutable states “shared promiscuously between various objects.”
“In most cases, OOP programs turn out to be one big blob of global state, [which] can be mutated by anyone and anything without restrictions,” he tells me in an email.
Suzdalnitski also believes that object-oriented code is harder to refactor and harder to unit test, and his essay builds up to a bold pronouncement that “It is impossible to write good and maintainable object-oriented code…”
And pity the poor developers. “Precious time and brainpower are being spent thinking about ‘abstractions’ and ‘design patterns’ instead of solving real-world problems, ” he wrote.
Suzdalnitski sees another major issue: concurrency. “OOP started it the era when our CPUs had one single core, and programmers hadn’t had to worry much about things like concurrency…” he tells me in his email. “One of the primary reasons for the rise in popularity of functional programming (as well as languages like Go and Rust) is their ability to effectively tackle concurrency.”
In fact, his essay ends by touting functional programming as the superior alternative — a competing paradigm in which problems are modeled not with objects but with pure mathematical functions and an emphasis on avoiding changes in state. Suzdalnitski sang its praises three weeks later with a satirical essay that appeared to dabble in reverse psychology. (“Functional Programming? Don’t Even Bother, It’s a Silly Toy.”)
It argues, for example, that functional programming “makes refactoring and unit testing unnecessarily easy,” and that it’s a misguided programming paradigm “based on mathematics (which obviously is inferior and has no applications in the real world apart from academia).”
Getting a Reaction
After Suzdalnitski dared to challenge this long-standing programming paradigm, it’s been interesting to read the heated reactions from other developers. Suzdalnitski’s first essay attracted 174 responses on Medium, including one from Texas-based software engineer Jesse Dickey, who argues that the name itself is a misnomer. “You are not really programming in objects, you are programming in classes. So you could almost want to call it class-oriented programming…” (He adds later that classes are more properly thought of as “custom types.”)
And a link to Suzdalnitski’s first essay also turned up in 10 different forums on Reddit, sharply dividing other real-world developers over which paradigm was ultimately superior — functional or object-oriented programming:
“I use oop languages, but write all my code (mostly typescript) in a more fp way. Its ridiculously simpler. Functions (pure as possible) and data live separately. Refactoring a messy oop codebase is such a nightmare, compared to a more pipelineish fp solution…”
“I looked at ‘pure functional programming’, but this was a disaster to work with. It is like working with a spreadsheet, without a spreadsheet…”
And soon commenters were debating whether to blame the paradigm or the programmers.
“Software has to be built by average [programmers], not elite programmers. If your grand paradigm or stack requires elite programmers, it will likely fail over time, as elite programmers are harder to keep around…”
“OOP as a paradigm incentivizes code obfuscation (which is for some reason confused with abstraction), while [functional programming] tends to make things as explicit as possible…”
Eventually and inevitably, this controversy spread to another essay online, arguing back with an equally provocative title: “Developers who hate on OOP don’t know how to use it.” It was written by Gary Willoughby, a UK-based software engineer whose profile says he indulges “in the craft of software development as a creative endeavor.”
In the middle of this back-and-forth, I wondered how Suzdalnitski felt about all the reactions his essays were getting. So I decided to reach out and ask him about his own long journey through the world of computer programming paradigms — and where this passion for functional programming really came from.
“I’ve been programming for most of my life, and the more experience I got under my belt, the more I started realizing that my code was bad, really bad,” Suzdalnitski told me in an email. It had been hard to figure out why the code was bad — but it wasn’t for a lack of trying. “I’ve invested a ridiculous amount of time over the years into my OOP education. It’s ironic that the return-on-investment was rather minuscule…”
But even simple features were taking an “unreasonably large amount of time” to implement — and the bigger the codebase, the harder it got. “Things started breaking more, and more often.”
But then in 2014, Suzdalnitski discovered F#, the multi-paradigm programming language released by Microsoft in 2010. “The language seemed weird, and elegant at the same time… But the idea of functional programming stuck with me.”
‘OOP Is Dangerous’
And today this has all convinced him that “OOP is dangerous. Nondeterminism inherent in OOP programs makes the code unreliable.” As the program executes, its flow can take many, many different paths — thanks to all of those different objects, with new objects sometimes even created on-the-fly. “The devastating effects that this seemingly innocent programming paradigm is having on the world economy is hard to comprehend.”
He thinks his strong opinions made some people angry. But a half-million page views later, I had to ask: had he heard anything that made him change his mind, or see things in a different light?
“There was one comment that really made me pause to think,” Suzdalnitski says — the idea that there’s an almost institutional undercurrent that keeps producing a glut of OOP programmers. “It makes sense for the managers to keep using OOP because the cheap OOP developers are easy to hire, and many fresh graduates are familiar with OOP.” But unfortunately, Suzdalnitski believes that they’ll end up paying for it down the line. Or, to put it another way, “OOP is prevalent because cheap OOP developers are readily available, while functional programmers are typically more smart, and more expensive…”
“The final product of course typically takes longer to deliver, is hard to maintain, and is often buggy due to OOP non-determinism.”
So Suzdalnitski began writing his online essays, because “If I can inspire a thousand people to question the benefits of OOP and give functional programming a try, then they will start writing better and more reliable code.” And with 500,000 views, he thinks he’s succeeded, setting the world on a path to happier developers, happier users, and companies saving money…
But he also says he had a more selfish goal.
“To make OOP companies think twice before contacting me for consulting.”