OOP: the worst thing that happened to programming [2/24/2025]

[gentlee]

Discussion of https://alexanderdanilov.dev/en/articles/oop

[ssachin520280]

I would like to read an article where the author has opposing views. This will help me draw a better conclusion. If you have a link to such an article, please share it.

[gentlee]

@ssachin520280 this article was posted on habr.ru and there are more than a thousand comments.

You can go to ru version, scroll to the bottom and press "обсудить: habr", and translate the page to en.

Or here is the link.

PS: But I'm afraid there is not a single comment out of 1000+ that demonstrates any advantage of OOP with classes over not using classes, with code example. However there are code "battles" where I implement every OOP example that "can't be done good with FP", provided by commenters, better than their own with OOP.

[sumim]

You wrote “dot notation, which first appeared in Smalltalk in the 1970s,” but I believe this might be incorrect. Could it be that you’re confusing it with “Simula in the 1960s”?

[gentlee]

Yes, thanks for pointing out. Fixed.

[larrasket]

Great article. I came here to see how people discussed it, apparently, sadly as well, people tend to silently downvote/thumdown what they don't agree with whenever they can not find a good reason why they don't like it.

[CybotTM]

People tend to perceive or portray others as incompetent simply because they are unwilling to justify their opinion.

Every opinion is justified, reasoned or not, even if you don't like it.

[rabinnh]

I've read this opinion many times. I never really used C# but I used C++ extensively, and I've seen object orientation grossly misused, mostly by developers that didn't understand it.

However, here are 2 examples where object orientation can be great (yes, I know there are other ways to achieve these without object orientation):

• Create a base class that performs functions that are reusable over and over. For example, a TCP server class that handles every thing in an event loop and has a callback to an implemented pure virtual function. Now any server can be created by implementing a single class derived from the one pointed to by the pure virtual function.
• Something like an event handler where the base class handles functions common to all events, but derived classes contain event specifics. New event? Just implement a derived class.

That said, in one sense I agree with the author; probably 85 out of 100 developers create complex, hard to debug messes with OOPs languages, But that's not the languages fault. I've seen impossible to understand straight spaghetti C code just as often.

[divol]

Reading you I sniffed some strangeness :
1/ yea, you don't need OOP to develop softwares, no need to attack OOP
2/ FP : you need a langage like CAML, FP is not just programming with functions
3/ you could write OOP programs without OOP languages : I knew one guy stating the best way to write OOP is with ASM, and my first Objects were derived from Pascal unique object "Object" very fun !
And from C , you just need structs, with functionPTR and union on structs , no much more ...

At last, I dislike c++, Java, python but Obj-C was my favorite OOP language , simple and compact

Thanks for your thread !!!
Jd

[rabinnh]

Funny thing about your statement is that I was defending OOP

[gentlee]

@rabinnh problem with such opinions is no code examples, which makes it useless.

Give some code example to see at least a single pro of using OOP over FP and we can discuss.

[mapokapo]

Why did they put this in the TLDR Dev newsletter?

[bsmalling]

Not sure. They like completely hung him out to dry. I barely had to aim.

[bsmalling]

Before you snag your diapers on the coffee table, get off your cloud mister high horse. Computer scientists like you complain about things not being ideal. Engineers deal with it. I was never informed that a snot-nosed little kid like you were the person who decided what a “true” engineer was. Missed the memo, apparently.

Computer scientists like you complain about things not being ideal, but that’s because they are smart, unlike you. Software engineers just deal with it and get the work done as best they can. You are obviously the former with a lot to learn. So shut up and get your work done.

In your main point, you chose to use a User class and not an IUser interface, or both, and then complained about your choice. Nice argument there, Aristotle.

You wouldn’t know KISS if dressed up in black leather, white face paint, and blew fire down your throat.

OOP was always and has always been about code reuse. That’s it. You seemed to have missed the whole fricking point. Write it in Sanskrit for all I care.

Good languages like C# and Python have both inheritance and delegation. Golang doesn’t. You just aren’t experienced enough to know how to use any of them. Obviously.

Regarding the banana and monkey problem (who’s Joe Armstrong?). That’s an implementation problem, not an OOP problem. Next time design your interfaces and classes better the first time around and you won’t have any fruity problems.

Usually, we learn how we should have designed our interfaces and classes AFTER the first version ships. If we ever get the chance, we try to fix those mistakes in version two. It sounds like neither of you are old enough to have worked on the version two of a large, complex software project. It sounds like I would have dropped you from the team early on, too.

At the end of the day, it’s all about readability. Will someone be able to read and understand your code tomorrow? That’s really the only goal of programming.

Come back in ten years. And in the mean time, try to learn something from your elders. I wouldn’t wipe Uncle Bob’s ass (or any of the other CS giants he mentions in his book) with a little punk like you.

Now, that’s what I wanted to write. But then I thought, you know, that’s kind of mean. So I just wrote this:

I disagree and I have a TON more experience in software development than you do in your “many” years.

So there, that’s my argument. You can ignore the first part.

[bsmalling]

Don't take it personally. I didn't imagine you when I wrote it. I have no idea what you look like. I was thinking of young, eager kids getting out of college and starting to work as software engineers. I was like that back in the mid 1990s. I was confident, a little arrogant, and made a lot of mistakes. I'm just saying your generation could learn something from my mistakes, too. Or Uncle Bob's mistakes. Or Bjarne Stroustrup's mistakes. But I can't see where you've proven that you understand what he did before you start spouting your own theories and dismissing his. Prove to me that you understand him, first. Then we can talk.

There's a reason the story of Icarus is like 2,000 years old. It happens with every new generation.

[Tobias-Reidarsen]

OOP has not always been about code reuse.
The early experiments with it were about modeling real world systems.

Casey Muratori has a pretty good talk where he goes through the early history of oop, and what they were trying to do.
(https://m.youtube.com/watch?v=wo84LFzx5nI)

[TonyMarston]

@Tobias-Reidarsen

OOP has not always been about code reuse. The early experiments with it were about modeling real world systems.

If you read Designing Reusable Classes which was published in 1988 by Ralph E. Johnson & Brian Foote you should see at the start where it says

In particular, since a major motivation for object-oriented programming is software reuse, this paper describes how classes are developed so that they will be reusable.

[Tobias-Reidarsen]

@TonyMarston

The talk in the video is about oop from the beginning. He shows how simula (the first oop language) was about writing simulations of real world systems. The motivations for code reuse and availability came later.

[TonyMarston]

@Tobias-Reidarsen

He shows how simula (the first oop language) was about writing simulations of real world systems.

Modelling the real world is only practicable when you are writing software which communicates with objects in the real world. When you are writing a database application you are communicating with objects in a database, and those objects are called TABLES, hence the need for a separate class for each of those tables. To add reusability to your code you need to look for patterns so that you can extract the similar from the different so that you can put the similar into a reusable module. In the case of database tables each one is subject to the same set of operations - Create, Read, Update and Delete - so each table class needs methods to support these operations. The way to deal with sharable methods is to move them to an abstract class so that you can share them through inheritance. But how do you add custom processing to the mix? The use of an abstract class means that you can implement the Template Method Pattern which contains a mixture of invariant/fixed methods and a number of variable/customisable methods which are also known as "hook" methods. Each table subclass can then override any of these hook methods in order to provide its own implementation.

I have written a large ERP application which contains over 400 tables, and each one of those table classes contains nothing but hook methods as all the standard code has been defined in the abstract class. That is a lot of code which I don't have to duplicate.

How often was Simula used to write a database application? Could it achieve the same level of reusability?

[Tidbit0519]

I started learning programing in college with Java and C#, and it was a pain to understand the different design patterns (to your point, it's battling the architecture rather than the business decision)... and later transitioned to JavaScript in my internships which I love the FP aspect of it, but missed the OOP's way of modeling relationships and object lifecycles (I guess I was hardwired to think in OOP in some ways from my education)

And recently, I got an engineeering job that uses Ruby. According to my understanding and experience so far, it is an OOP language with quite a bit of FP features, and I think it's a sweet spot for me!

I do have a question, how would FP handle lifecycles? I had Claude spit out a rough comparison between OOP and FP:

OOP example:

class Book
  attr_accessor :status, :borrower
  
  def checkout(patron)
    @status = :checked_out
    @borrower = patron
  end
  
  def return
    @status = :available
    @borrower = nil
  end
end

# Usage - mutate the object
book = Book.new(status: :available)
book.checkout("John")  # book changes
book.return             # book changes again

FP example:

# Just data + functions
def checkout(book, patron)
  {**book, status: :checked_out, borrower: patron}
end

def return_book(book)
  {**book, status: :available, borrower: nil}
end

# Usage - create new versions
book_v1 = {status: :available, borrower: nil}
book_v2 = checkout(book_v1, "John")    # new version
book_v3 = return_book(book_v2)          # another new version

It seems like OOP is able to track the lifecycle of an object, whereas FP has to create different versions of it due to its immutability nature.

[gentlee]

Article is not about math-functional immutable style of programming, mutability is totally fine without classes the same way.

type Book = {
  checkedOut?: true
  borrowerId?: string
}

const book: Book = {}

const checkoutBook = (book: Book, borrowerId: string) => {
  book.checkedOut = true
  book.borrowerId = borrowerId
}

[Tidbit0519]

Sorry, I'm scratching my head a little right now. would't this be more of a procedural programming, and I do want to point out the "procedural style" in the article, which I haven't heard of as part of FP...

I always thought of procedural as a completely different paradigm (which you also pointed out in the article) and I believe languages like JavaScript started out to be PP as well. In standard FP, immutability and pure functions are considered core principles. Not sure if you're calling this example as FP, but so calling this mutation-based code as "FP" seems contradictory to me.

[gentlee]

You probably skipped a lot while reading the article. There is a "Definitions" section and even a "Common Objections" section with me commenting "Functional and procedural programming are different things." objection.

Also, using closures, first-class functions and mutable / immutable approaches together is not PP.

[Tidbit0519]

I did read those sections, and I did mention in my previous comment that you have pointed those things out in the article, and I apologize if I wasn't clear enough.

I see what you're saying with the mix of approaches. I guess I was quite hung up on pure FP being immutable. Thanks for your clarification.

[shevit]

Try reinveting DOM (Document Object Model) for the web without OOP :)

[shevit]

I mean that DOM is one of the most important success stories in IT industry. Maybe the most impactful one. And it's full OOP. So saying that "OOP is the worst thing that happened to programming" is at least immature.

DOM's OOP feels natural (here we have encapsulation, inheritance, polymorphisme, etc.. ) and it all make sense. .

[larrasket]

@shevit: This example is completely irrelevant. You can have a very successful software written in an esoteric programming language like brainfck, this does not have anything to do with brainfck’s paradigm being a good choice for modern software. Many successful software out there uses FP, but non could be used to support the case here because it’s just irrelevant. However, it has been proving, empirically, that OOP encourages very bad practices by users, multiple inheritance, over-abstractions, notorious design patterns, are some examples.

[shevit]

@shevit: This example is completely irrelevant. You can have a very successful software written in an esoteric programming language like brainf_ck, this does not have anything to do with brainf_ck’s paradigm being a good choice for modern software. Many successful software out there uses FP...

the mention of brainfuck IS irrelevant. Also, it does not matter what language was used to make a browser. DOM is an interface, The interface based on the OOP concept. Also it's worlds most widely used interface. Can you think of any other interface (API/Library) being used as widely as DOM?

So, in this precise example the application of OOP concept to make the HTML dynamic and programmable was a huge success. Simple and clear.

But it's obvious that other tasks (especially on the server side) might not need the OOP. Server-side frameworks tend to use OOP only for better package structuring and dependency injection. Some don't use OOP at all.

Few years ago I've seen a blog of yet another OOP basher. Basically there were 2 subjects : "OOP is bad, because you bring the whole jungle (dejavu citations)", and "Angular is the best framework because it promotes the structured code" . It made me laugh : Angular is the most OOP oriented framework of all :)

OOP encourages very bad practices by users, multiple inheritance, over-abstractions, notorious design patterns, are some examples.

Shall we discuss the difference between "allows" and "encourages" ?

So there is a problem and there is a solution, in IT each problem can be solved in a thousand ways and is solved in a thousand ways by different people. Just to explain that OOP is not the worst thing.

The worst thing in programming languages is over-use of constants forced by badly tuned sonarqube rules :)

ORMs are quite a disaster too, it encourages the pattern "I'm a modern developer I don't need to know SQL, I use ORM"

[gentlee]

@shevit first, no, you said exactly "try reinvent DOM without OOP", implying that it is not possible with FP. But OK, it seems that you retracted your words here.

Secondly, DOM is a failure story because:

• it is too heavy
• it is too tightly coupled

• it is too slow

• it is too hierarchical

• it doesn’t fit well with modern reactive/functional UI models, that’s why modern frameworks minimize their interaction with the real DOM.

There is lots of garbage because of OOP hierarchy like HTMLFontElement, HTMLMarqueeElement and many more (which would be just a generic struct in FP case with type field, not a separate class), it is hard to clone / copy, serialize. Also DOM elements are basically lazy dynamic wrappers around native C/C++ structures which are much closer to FP, otherwise it would be even much slower.

Also, there is a TON of duplication through all html elements, like fields: disabled or method clicked - because of OOP design.

So using OOP for DOM is actually a great architectural failure and became a huge pain in the ass for browser and app developers, and made browsers the slowest platform for decades.

[shevit]

How lovely to see people who think they would write a better, lighter and much faster browser. Keep that spirit !

Otherwise, saying you can and actually being able are 2 different things.

[CybotTM]

Netscape Navigator vs Internet Explorer, or to stay in programming: Procedural vs Object-Oriented, Static typing vs Dynamic typing, Server-side vs Client-side, Monolith vs Microservices, Relational Databases vs NoSQL, Native apps vs Web apps ... it's all the same, all the same unnecessary wars that waste resources. They are two different concepts that address different problems and have different strengths and weaknesses. It depends!

Btw. the worst thing ever happened to programming is US american date format "2/24/2025" ;-)

[gentlee]

This article is trying to prove that OOP has no advantages and is actually a 100% anti-pattern. There are lots of points with code examples. You are just providing your opinion without arguments and without code, and honestly opinions are not much needed here.

[CybotTM]

Yes, you're right, that's why no one offers a counterexample… or they're simply bored or disgusted by your unreflective writing style. Believe what you want.

In your introduction to this discussion, you didn't state what's "necessary" here. You should clarify that if you don't want to hear any opinions.

[simon-tamman]

and is actually a 100% anti-pattern

100%?

[TonyMarston]

From your list of complaints against OOP it is clear that you don't know how to implement it properly. A poor workman always blames his tools, and if you are incapable of writing effective software using nothing more than encapsulation, inheritance and polymorphism then you are not much of a programmer. I worked in other languages for 20 years before switching to PHP in 2002, and I taught myself OOP based on my personal experiences. I have been told time and time again that my methods are wrong, that I am not following best practices, but my critics are missing a very important point - my methods cannot be wrong because they work. I do not follow their version of best practices as I prefer to follow a different set of practices which produce better results, ones than produce far more reusable code than they can shake a stick at. You can read one of my numerous articles at A minimalist approach to Object Oriented Programming with PHP

[siltus]

I mean, everyone is entitled to their opinion, but clearly you never worked on real complex projects with many contributors if you suggest functional programming, which belong maybe in projects of 2-3 people that really like math. I've been programming for the better part of the last 30 years, in dozen of languages, in various disciplines and while I had enough misery handling badly written OOP code, the issue was always incompetent programmers more than this or that technology.

Besides sentences like "why experienced Java (C#, C++, etc.) programmers can’t really be considered great engineers, and why code in Java cannot be considered good." begs the question if the writer of this "article" has ANY real-world development experience, writing real complex solutions that servers millions of people daily (I did, multiple times). Some humility and self consciousness won't hurt.

[sjBao]

I can't imagine you really feel that strongly about OOP after having many years of experience.

At the end of the day, everything is about trade-offs, and programmers can shoot themselves in the foot with FP just as easily.

I also think it's important to consider the historical context of why things were introduced. Even if you really hate OOP, alternatives at its time might not have been viable/feasible or just worse.

Or course we should always seek to improve upon past wisdom, but to discount them wholesale because of some inconvenience you encountered seems disingenuous/unwise.

But in the age of information, you gotta create some buzz I guess. It certainly got me to reply

[simon-tamman]

why are people so obsessed with "versus"? Functional and OOP ideas can compliment each other. You don't need to frame OOP as some sort of injustice that your generation must be at war with. It's good for some things and less good for other things. To frame it as only right or wrong is just childish, who is the author trying to impress, exactly? I find either style of code readable and I think many of the points the author makes are stretched. They're just not very good at writing/reading OOP code, its ok, most developers aren't good at reading or writing code at all, if you find something that works for you; great. But you don't have to shit on something else in order to express that.

[larrasket]

In fact, I didn't bother to read his code, but the jokes about him in the r/PHP community made me curious. Here's an example: https://github.com/apmuthu/radicore/blob/551c8e445c96f8a04ca96a2b538d35e7014552cd/radicore/includes/std.table.class.inc

One of the worst code I've ever seen in my life.

[TonyMarston]

@Tobias-Reidarsen

Whoops! Here is the correct link to that challenge.

[Tobias-Reidarsen]

Thank you @TonyMarston

[TonyMarston]

@larrasket

One of the worst code I've ever seen in my life.

Try looking at some of the email libraries you can download using composer. Thinking that having over 100 classes to send an email is far worse than having a single abstract table class that contains all the boilerplate code for every concrete table class. The contents of that abstract class are functionally related, therefore satisfy the principle of high cohesion on which SRP is supposed to be based. This is what a "best practice" looks like.

[TonyMarston]

@larrasket

Here's an example: https://github.com/apmuthu/radicore/blob/551c8e445c96f8a04ca96a2b538d35e7014552cd/radicore/includes/std.table.class.inc

That link is over 7 years old and things have moved on since then.

[shevit]

How an LLM sees us humain arguing here: 😀

Jokes About OOP

Why do OOP programmers never die? They live on through inheritance, and their kids keep overriding their garbage methods forever.

Java devs walk into a bar. Bartender: “What’ll it be?”
47 factories, 12 interfaces, and one Spring context later… the beer arrives lukewarm and over-encapsulated.

Real OOP gangsters don’t use public fields. Everything private, 400 getters/setters just to flex on procedural peasants.

C++ programmers hate OOP until multiple inheritance shows up. Then they marry two base classes and spend a decade debugging the diamond-problem divorce.

OOP résumé: “15 years crafting beautiful abstractions that hide the fact I still don’t know how memory works.”

Jokes About OOP Haters

OOP haters: “I love simple code!” → writes one 4000-line C file with globals named x, tmp, and pls_work.

“Inheritance is evil!” says the guy whose codebase is a single god function called do_everything_and_kitchen_sink().

Functional bros roast OOP while their “pure” Haskell app needs three PhDs and a blood sacrifice to print “Hello World” without side effects.

“I hate objects, I’m a real systems guy!” → writes raw assembly, chases segfaults for six months, cries when a 20-line class fixes it.

OOP haters in 2025 still quoting that one 90s rant while secretly using Python classes daily because “it’s just syntactic sugar, bro.”

React functional purists bragging about hooks and “no classes” while doing const [state, setState] = useState() — my brother in Christ, you just reinvented private encapsulated state with extra steps and a worse devtools experience. Congrats, you encapsulated your encapsulation inside a functional LARP