In this article, we will try to understand why OOP is the worst thing that happened to programming, how it became so popular, why experienced Java (C#, C++, etc.) programmers can’t really be considered great engineers, and why code in Java cannot be considered good.

Denis Bolkovskis

Anthropic

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

The post argues that object-oriented programming (OOP) is detrimental to programming and discusses its drawbacks compared to functional programming (FP). It highlights issues with OOP constructs such as classes, methods, inheritance, and encapsulation, and claims that these contribute to overcomplicated code and poor programming practices. The author recommends avoiding OOP in favor of FP, which is seen as simpler and more efficient. The post suggests adopting languages and techniques that favor functional paradigms.

OOP: the worst thing that happened to programming

I recommend combining the best of both worlds. OOP also has massive advantages if done right, like easy modeling of complex data, imo a functional oop approach is the best way forward. Languages like C# are heading in a good direction. But of course your code quality will always be limited by your understanding of the paradigm. pure oop can be really nice if used properly and fp can go horribly wrong if you don’t know how to use it.
I agree that pure oop is suboptimal. Unfortunately this article shows deliberately bad examples. Either the Author lacks crucial understanding of how to use OOP or deliberately made bad examples.

Maybe I just missed it, but was there ever any serious consideration to any drawbacks of functional programming? There were definitely ones given for object-oriented. So that alone makes this very lopsided and hard to give real consideration to.
Also, when you say things like this:
<blockquote>
I am absolutely sure that a person writing commercial code in a purely OOP language for more than 3-4 years, who hasn’t noticed many of its problems and hasn’t started thinking about transitioning or switching to FP — cannot be considered a skilled engineer. A true engineer always thinks about the simplest solutions, notices flaws and complexities, and cannot miss such a log in the eye.
</blockquote>
You’re missing the beam in your own eye. It could be rephrased as:
<blockquote>
If you haven’t come to the same conclusions I have then you are stupid.
</blockquote>
Have your opinions, extol the paradigms you like, but anyone selling you on the “one true way” is lying.

<blockquote>
why experienced Java (C#, C++, etc.) programmers can’t really be considered great engineers
</blockquote>
In other news FP apologists continue to be arrogant nitwits, mind you there aren’t the only ones, but god knows how but FP evangelists have this incredible talent for producing for most infuriating texts ever written.
Hey sunshine, no programming language or paradigm is a panacea that will magically solve all the problems you will every come across, they are man made things with specific design choices meant to solve a set particular problems, not all the problems;

At least, i have to give credit that he actually gives the definitions for what he believes every concept in the text are.
The author doesn’t seen to even understand the basic difference between paradigms, and hits a lot of strawmans to make procedural programming with parametric polymorphism look something awesome.
For some brief examples, in the method section turns out that he seen to not even know what partial application is, because any method is essentially a partial applied function looking by FP standarts, and this is one of the most useful things in FP, and so is in OO.
The claim that OO doesn’t know how to handle null is a joke, since its one of the textbook examples of how subtype polymorphism could be useful as you can write a null object or generalize this in a monadic-ish optional like Java did.
As for method overriding, he didn’t even override the method on the procedural example, just applied what would be equivalent to the LSP principle in OOP.
His inheritance example is basically an interface since interfaces are isomorphism to sum types in algebric systems.
In the polymorphism example his functions aren’t even polymorphic and each new shape would require to modify the getArea function that is exactly what you are trying to avoid with polymorphism, TS was such a bad choice for this example, because he would only be able to express the idea that he wanted in a language with ad-hoc polymorphism, but i guess that this is too much to ask from someone that doesn’t even understand that there are a lot of types of polymorphisms and that they don’t solve the same problems, thus leading to the expression problem.
As for encapsulation, the author seen to get from nowhere the problems with encapsulation since he don’t have a good point to criticize here. Encapsulation is essential in any paradigm, since its the ability to make sure that pre and post-conditions do apply for a code, and this is critical to any code that have business rules.
His argument about syntax is just cherry picking.
About design patterns i could cite every algebraic structure like Monad, BiFunctor, etc, or technics like partial application and currying and i would be as dishonest as the author.
Design patterns are common abstractions that emerge in every language and paradigm, calling this workarounds is just don’t understand the concept at all.
For constructos, maybe the author should check out better things like constructor promotion on TS itself or go take a tour in languages like Kotlin to review this point of they just being boilerplate.
His point about DI is just admiting that he doesn’t have idea of how DI is handled in most OO languages, since one of the biggest reasons for using DI Containers is having constructors.
And last, the point about array its just incoherent, he shows that in an OO design, you can just handle the problem as you would in procedural way, and then proceeds to say that in procedural way is the best. Also he complains about not being able to handle the problem because the data structures would be fundamentally different, but then turns out that OOP with encapsulation and polymorphism are exactly what would be an ideal solution for a problem like this.

in a gist, the author is saying that he is either bad at programming or a complete moron.