Goodbye, Object Oriented Programming

https://blog.devgenius.io/goodbye-object-oriented-programming-a08e1bd0b872?gi=fae95b4a4f21

by geekydev • 4 years ago

19 60 4 years ago

blog.devgenius.io

FpUser5• 4 years ago

The author should read less propaganda, do not get too excited about just a tools, and not to try to use same hammer for every job. Suddenly he'll find out that each paradigm has its place along with pros and cons depending on situation.

deltaonefour23• 4 years ago

I think we all agree though. OOP is, in practice used as a hammer for EVERY job when it is actually a tool best used for something extremely narrow.

Two of the most popular modern programming languages that just came out within the last decade eschew OOP all together: Golang and Rust.

A lot of people will argue about the semantics of OOP and whether golang or rust fits the paradigm in terms of the definition. Let's just make it simple. Whatever OOP methodology python, java or C++ is doing... golang and rust are not doing it.

FpUser5• 4 years ago

"OOP is, in practice used as a hammer for EVERY job"

It is NOT. If you're talking dumb developers it is their problem.

Golang is strictly corporate language with very defined goals and using it it as a hammer is just as dumb. Along with Golang Google using other languages just fine. For example they have huge pile of C++ which supports many paradigms, OOP including.

I do not understand these holy wars where everyone has to adopt "THE ONLY TRUE style, practice, language etc". I think this is really near sighted.

I am not using Rust at all so can say little how good it is "hammer wise"

JohnDeHope• 4 years ago

This link (to devgenius.io) is to a plagiarized copy of the original, which is here: https://medium.com/@cscalfani/goodbye-object-oriented-progra... .

Update: The way I figured this out is that I mod a subreddit called OOP Is Bad. I usually jump the gun on new articles, and then I have to roll back my posts when I realize they're duplicates. Anyway if you want to read up on the subject, you could do worse. http://reddit.com/r/oopisbad

geekydev• 4 years ago

Ho that's bad. I really didn't knew. I sent a message to DevGenius on twitter and they took the article down.

Thank you for letting me know, and apologize for sharing it

wayoutthere• 4 years ago

Grain of salt, author is a student (edit: apparently it’s just plagiarized) just learning of these things. OOP is not inherently good or bad, it’s just one tool in a toolbox. Yes, it’s more of a pain in the ass to write, but is much easier for a large, distributed team to maintain and improve upon.

clem• 4 years ago

As mentioned in the article's comments, this appears to be an article by another author reposted wholesale without attribution:

https://cscalfani.medium.com/goodbye-object-oriented-program...

petilon• 4 years ago

OOP isn't perfect, it is just the least imperfect among alternatives. Something better will come along, but FP ain't it. Because OOP maps well to how humans think, "something better" is going to be refinements of OOP as opposed to total replacement of it.

bcrosby95• 4 years ago

If you do OOP how "humans think", then you are likely doing it wrong. This is why OOD produced by both novice and intermediate experienced devs tends to suck, moreso than other programming paradigms.

deltaonefour23• 4 years ago

I have a set of tasks for someone to complete. How would I record those tasks on paper?

I certainly don't use OOP or FP. I write it as a list of procedures.

From this common use case we can know that Procedural programming is the default way humans think.

pseudosavant• 4 years ago

All humans don't think alike though do they? I'd sum up my unintentional journey from OO to FP as the realization that I'm not smart enough to do non-FP. Not saying OO is "wrong", but that maybe it maps better to your mental model than it does mine.

I can easily jump into a more functional oriented codebase and reason about functions with clear input/output and no side-effects. The realtime REPL compiler in my brain can track the private state of functions. And while not all functions can be 'pure', most can be. With OO? Forget about it. Side-effects everywhere, that often aren't obvious when you are new to a codebase.

And when I say "new" I mean it as in "not currently very familiar with". Which includes code I had written myself - years ago - that I have to relearn.

wvenable17• 4 years ago

This article is not really worth reading if you've read any criticism of object-oriented programming from the last 3 decades. Except maybe the reference problem related to encapsulation -- that's just wrong.

I really don't have these kinds of problems; it's likely due to experience. It's not that I don't use inheritance, encapsulation, polymorphism, etc. I do. And when I do, it works exactly as it's supposed to. I don't over-use it, I don't use it when it's not appropriate. This is the same with functional concepts as well.

Object-oriented programming is the most successful programming paradigm in history. But you don't get to the front page of hacker news with that information.

deltaonefour23• 4 years ago

Object-oriented programming is the most successful programming paradigm in history

No it's not. Likely the most popular paradigm. Not the most successful. It's like saying Null is the most successful concept in all of computer science.

wvenable17• 4 years ago

Object-oriented concepts are everywhere, even in software products like the Linux kernel, that don't use an object-oriented language. I'd go so far as to argue that 99.999% of all software is object-oriented (and I'm probably missing a few nines).

But you're just saying that's merely popular and not successful? That seems extremely flippant.

Zababa3• 4 years ago

Object-oriented programming is the most successful programming paradigm in history.

I don't think it is. The vast majority of code is imperative, with sometimes classes here and there, and these days with sometimes higher-order functions here and there, and with sometimes declarative programming (SQL and stuff like that). But the core is imperative code.

wvenable17• 4 years ago

Imperative code is the basis for almost everything -- whether it be OOP or functional or big ball of mud. It's not a significant distinction for this discussion.

lamontcg• 4 years ago

I've been thinking about this a lot lately, and my current view of the world is that inheritance as a way of implementing code reuse leads to poor mental models and practices.

A better approach is probably to implement the code reuse model as an implementation of a public interface, which the subclass then implements and delegates. The cause of the brittle base class problem is likely that the interface between the base class and the subclasses is often not defined very well so it tends to not get engineered very well, and then external code can depend upon the implementation of the base class creating the brittleness.

So instead of having Banana and Orange that inhert from Fruit and having a container like a List<Fruit> if you use composition instead you get Banana and Orange that implement IFruit through delegating to Fruit and your containers are List<IFruit>'s now (you can't see the details of how Banana and Orange implement IFruit they just promise to implement it). You are now free to create FruitV2 which is a snazzy new implementation of IFruit, and you can inject it into Banana and Orange without breaking anyone who depends upon IFruit. It also becomes more apparent when you are making breaking changes because you wind up editing IFruit. You can also use DI or a DI Container (if you must) to control injection of behavior into objects.

And really inheritance is just delegation to another class dressed up and made simple to use. It is the exposure of that base class publicly and without good interface design that makes it bad.

Implicit in what I just wrong there though is that encapsulation is a very good thing and you should only depend on interfaces. I don't know why the author argues that encapsulation is bad. I've lived in the ruby land for 10 years with no encapsulation and in the long run it is literally fucking horrible since anything can have been accessed by some user somewhere with tools like `send()` and any change can potentially be breaking, and users will whine about SemVer even though you certainly never documented what they were doing and would have yelled loudly at them for attempting it if you'd ever known. Fences and neighbors and the tragedy of the commons and all that....

zwieback• 4 years ago

Very good critique but from beginner perspective. Even back in the pre-Java days Uncle Bob and Scott Meyers taught us how to deal with these issues to some degree.

The other thing most OO practitioners quickly realize: real world things often don't make good object hierarchies or even classes.

OO has not delivered on its promise to partition large scale problem domains effectively, especially for statically typed languages, but maybe in the age of webapps and microservices it doesn't matter as much. The problems we struggled with in the 90s are not as relevant today.

deltaonefour23• 4 years ago

The standard reply by most people is:

   OOP is just a tool within a toolbox. You need to know how to use that tool.

I'm tired of reading this cookie cutter opinion. Can we go deeper?

I want to discuss why someone like linus hates C++. The extremities of these opinions are what's worth discussing here because we all can easily get behind the whole "Apples and Oranges" argument. The extreme arguments are the ones that are harder and more interesting. It takes more depth and understanding to develop an opinion beyond the cookie cutter one we see everywhere.

Do you love OOP and think it's better than FP and Procedural programming? Or vice versa? I want to hear your opinion.

wvenable17• 4 years ago

I want to discuss why someone like linus hates C++.

Personally reading some of Linus's complaints about C++ seem a little misplaced. And yet, I don't disagree with him either. He says C++ is a terrible language and it's really hard to disagree with that -- not because it's object-oriented but because it's C++.

When I was taught C, we were taught to carefully separate things to avoid trouble. If you're building a linked-list library, you don't export the struct definition you use abstract data type. You prefix your function names to make a namespace. The Linux kernel uses vtables in C to implement polymorphism for various drivers (e.g. different file systems with the same interface). OOP makes these things explicit.

trumpeta• 4 years ago

Torvalds (I think):

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

The problem with dogmatic OOP is that it mixes data structures and code into one. This leads to hard to modify code, unexpected side effects, poor parallelism. Imperative or FP code does the minimum to define what the data should be shaped like and then has a bunch of functions that either modify it or do some IO with it.

That's a lot easier to trace through and reason about. That in turn leads to more malleable code, which lets you evolve it faster as your understanding of the problem domain evolves.

Goodbye, Object Oriented Programming

Related Stories