Live data from Hacker News

The Case Against OOP Is Wildly Overstated

medium.com

11–20 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#11
post #5
post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

Agreed. The biggest problem with OOPS lies in its original premise: that code and data should be the same thing! This is grevious error, IMHO, that leads to nothing but problems: endless boilerplate code, lots of "interfaces" that essentially do nothing (that couldn't be done directly with said data), and debugging nightmares. I much prefer to work with systems where code and data are separate and never the twain sha…

OOPs original premise is homoiconicity? Really?

Re: The Case Against OOP Is Wildly Overstated

#12
I find the premise of this kind of article is flawed. Not because some of what the article says is incorrect, but because there is no such thing as OOP. OOPs as practised in Java, say, is very different from that in Rust (which the article mentions as having a "slimmer set of object-oriented features"). As a result trying to make generic statements about OOP doesn't really give much value IMO. You need to discuss specific well-defined programming practices to make progress.

I also don't think trying to define OOP is fruitful. One can resort to textualism, going back to Alan Kay's definition for example, but this is as bad in programming (how does this definition relate to current practice?) as it is in law.

Re: The Case Against OOP Is Wildly Overstated

#13
post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

The entire point of OOP is to encapsulate state within objects and to have objects communicate through messages, that is to say to 'program without a center'. Global or interconnected state is if anything a violation of OO principles.

In proper OO state is hidden and insofar as it causes issues it does so in a way that is handled by the object rather than the program overall.

Also treating code as data isn't a feature of OO, it's an old idea starting with Lisp and metaprogramming I suppose and it's present in functional languages as well. It basically just means that the language itself is a first class data type within the language.

Re: The Case Against OOP Is Wildly Overstated

#14
post #3
post #2

In summary, "Object Oriented Programming is good when you don't orient your program around objects."

That sounds snarky. Not sure if that was intended or not, but regardless I read your comment as: "OOP is good when you use the object oriented structure as a tool to organize your code and data to solve a problem, but not when you try to wrap your solution or your conception of the problem itself around OOP." It's 2020, and after 50+ years of programming language research I think it's safe to say that there is no "on…

> I think it's safe to say that there is no "one language to rule them all" or "one programming paradigm to rule them all.

Absolutely! But when OOP was initially sold to the masses it was marketed to be that one solution to rule them all, OOP was the buzzword of the day and it stayed like that for some time to come. It is only fair that the king was dethroned to make room for equally good/competing paradigms.

I don't think OOP is bad but I've seen codebases where it become needlessly more complicated and complex than it should have been.

The author is absolutely right in claiming that OOP is not bad if certain things are avoided when: objects are exactly not paralleling the real world, avoiding inheritance when not coding a framework/library, not creating objects unnecessarily, not overusing design patterns, etc. But since it was heavily marketed those things could not be easily escaped from and the OOP gurus kept on adding to the list. OOP is not bad but it deserve its bashing for the hype it took the world over with.

Re: The Case Against OOP Is Wildly Overstated

#15
It seems to me that the definition of OOP is so unclear as to make the term useless. It seems to me that lots of really bad ideas were spread under the guise of OOP. But now OOP advocates are shifting the definition so that OOP either excludes are doesn't explicitly advocate those bad ideas. I have to wonder: what exactly does OOP still advocate?

Re: The Case Against OOP Is Wildly Overstated

#16
post #8

The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…

Always prescribing raw sql is dangerous: You typically want something managing your sql queries if there's user input because scrubbing out SQL injections is hard and it's not something you should be 'rolling your own'

Re: The Case Against OOP Is Wildly Overstated

#17

IMHO if a programming philosophy leaves so much room for interpretation and misunderstanding, rants and counter-rants, needs evangelizing to the "dumb masses" what it "actually" means, and all of that hasn't been settled after more than half a century, then it has turned from a philosophy into a religion (or rather, a cult). Just let it rest and move on. It's just a waste of time for everyone involved.

I think it's telling that I'm not able to tell whether you're talking about OOP or FP in this comment.

Re: The Case Against OOP Is Wildly Overstated

#18
IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.

Re: The Case Against OOP Is Wildly Overstated

#19
post #3
post #2

In summary, "Object Oriented Programming is good when you don't orient your program around objects."

That sounds snarky. Not sure if that was intended or not, but regardless I read your comment as: "OOP is good when you use the object oriented structure as a tool to organize your code and data to solve a problem, but not when you try to wrap your solution or your conception of the problem itself around OOP." It's 2020, and after 50+ years of programming language research I think it's safe to say that there is no "on…

I program video games; I would consider running a real-time simulation as a "state-rich" problem domain. And the constraints of running real-time simulations mean that some implementations are not acceptable. Things are not generally allowed to be slow if they can be done in a way that is fast.

Because of this, many game engines are built in a way that allows high throughput for processing the state of hundreds, perhaps thousands of entities in the world. Our guiding paradigm could be described as an entity-component system; another word used to describe it has been "data-oriented design." Here's a talk about it by the guy who was our engine director at the time[0]. It is not object oriented, and it seeks to unshackle itself from many of the issues with OOP as a guiding principal.

[0] https://www.youtube.com/watch?v=rX0ItVEVjHc

Re: The Case Against OOP Is Wildly Overstated

#20

I find the premise of this kind of article is flawed. Not because some of what the article says is incorrect, but because there is no such thing as OOP. OOPs as practised in Java, say, is very different from that in Rust (which the article mentions as having a "slimmer set of object-oriented features"). As a result trying to make generic statements about OOP doesn't really give much value IMO. You need to discuss spe…

Ruby implements the Kay concepts under the hood, and erlang is arguably a rather faithful implementation of Kay objects (though the code one writes doesn't semantically reflect that and it was developed independently for a completely different set of reasons - fault tolerance)
Post reply on HN