Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case Against OOP Is Wildly Overstated

medium.com

Post reply on HN
Print view View original

221–230 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#221

Post by Gibbon1 »

fdupress wrote: post #146
keithasaurus wrote: post #130

Earlier quoted context omitted.

> "Tightly binding data and code" allows you to maintain complex invariants via code Not sure I understand what this means. Could you give an example?

A good example would be a complex state machine, where you rely on the fact that the state is only modified by the state machine code to make sure it remains well-formed, and the control-flow itself heavily relies on the state being well-formed (think of a TLS session, for example). But then again, what you want there is modularity, which OOP provides, but is also well-supported in other paradigms.

Yeah but you don't need OOP to do that. See opaque pointer's in a number of non OOP languages.

Re: The Case Against OOP Is Wildly Overstated

#222

Post by Animats »

One point I've made occasionally is that few languages support backpointers well. When B is a member of A, B often needs a back reference to A. Rust does that badly, because it doesn't fit well with the ownership semantics. C++ with move semantics does that badly, for much the same reason The same thing applies when A allocates and owns B. It's hard to get a clean, safe, reference back to A that cannot result in a dangling pointer, especially during deallocation.

Object inheritance does that well. Finding the parent is easy and is done in a consistent way. The deletion process is done in a consistent, if not ideal, way. That's useful.

If we had proper syntax and semantics for getting a reference back to the owning object, one of the use cases for inheritance would go away. Languages have "this" or "self", for accessing the current object, but lack "owner", for accessing the owning object. If a language offers single ownership, you should be able to find the owner easily.

(Multiple inheritance is just a mess. Most, if not all, of the use cases for that are better done in other ways.)

Re: The Case Against OOP Is Wildly Overstated

#223

Post by addicted »

meheleventyone wrote: post #152
addicted44 wrote: post #109

Earlier quoted context omitted.

Hash maps also don't (usually) have external effects. There arent many hash map methods that will actually modify the data. Standard OOP, on the other hand, seems to encourage such behavior. So, for example, a Company object could contain a bunch of Department objects, each of which contained a bunch of Employee objects. These people objects could also be referenced in areas outside of the company object. If I called…

I think the problem is that your example is too contrived and you can hide implementation details by just having a function giveFinanceDepartmentARaiseInDollars(company, dollarAmount) that exhibits the same issues as the “object oriented version”. More generally the issue of global mutable state and keeping your own sanity as a developer is a problem across paradigms.

The real problem with my example was that I modified the strict instead of returning a new one.

My “functional” code wasn’t actually functional.

If I had written that correctly, by returning a modified copy using a map instead of modifying the strict in a loop, your example would also be covered, because the function you’re describing would not modify any of its inputs, but instead would return a new copy. And the function wouldn’t have any side effects either, so it would once again be completely clear what’s happening.

Re: The Case Against OOP Is Wildly Overstated

#224

Post by mrkeen »

brundolf wrote: post #209

The best thing I can say about OOP is that it allows for private state that only certain logic is allowed to know about. In some cases, you just really need that. But I think the biggest problem with OOP is that it encourages a spirit of "eager complication". Take getters/setters as a classic example. Occasionally that pattern can be useful, but standard practice in Java is to never ever create a simple public field.…

> The best thing I can say about OOP is that it allows for private state that only certain logic is allowed to know about.

Local variables in methods are private and encapsulated. Languages had this before and after OO. Plus modules/namespaces/headers/etc.

OO languages added classes with fields, which are variables shared among methods (whether they are declared with the private keyword or not.) The opposite of private/encapsulated.

If the 'private' keyword made a class's state sufficiently private I wouldn't need to worry about the difference between StringBuilder and StringBuffer, and I could pass java.util.Date without fear.

Re: The Case Against OOP Is Wildly Overstated

#225

Post by brundolf »

mrkeen wrote: post #224
brundolf wrote: post #209

The best thing I can say about OOP is that it allows for private state that only certain logic is allowed to know about. In some cases, you just really need that. But I think the biggest problem with OOP is that it encourages a spirit of "eager complication". Take getters/setters as a classic example. Occasionally that pattern can be useful, but standard practice in Java is to never ever create a simple public field.…

> The best thing I can say about OOP is that it allows for private state that only certain logic is allowed to know about. Local variables in methods are private and encapsulated. Languages had this before and after OO. Plus modules/namespaces/headers/etc. OO languages added classes with fields, which are variables shared among methods (whether they are declared with the private keyword or not.) The opposite of priva…

> OO languages added classes with fields, which are variables shared among methods

That's not true. Structs and other mutable, structured data objects existed long before OOP. The differentiating factor was that no functions/methods were able to have varying levels of access to those fields; everything was public all the time.

> The opposite of private/encapsulated.

I don't think that's fair. OOP added "private variables that survive past the end of a function", if you want to get pedantic, but I think there's plenty of added value to having this functionality in your toolbox. And yes, technically closures can accomplish the same thing, but most mainstream languages did not have them yet when OOP was on the rise and even then, using them to achieve "lasting, private, mutable state" is, IMO, one of the few cases where the OOP way of doing things is actually more ergonomic and expressive of intent than the functional way. OOP is fundamentally about state, so when you really have to manage some state, it is often the right way to do things. The problem comes when you assume preemptively that you need state in the first place.

Re: The Case Against OOP Is Wildly Overstated

#226

Post by augustk »

Gibbon1 wrote: post #221
fdupress wrote: post #146

Earlier quoted context omitted.

A good example would be a complex state machine, where you rely on the fact that the state is only modified by the state machine code to make sure it remains well-formed, and the control-flow itself heavily relies on the state being well-formed (think of a TLS session, for example). But then again, what you want there is modularity, which OOP provides, but is also well-supported in other paradigms.

Yeah but you don't need OOP to do that. See opaque pointer's in a number of non OOP languages.

These are called Abstract Data Types.

Re: The Case Against OOP Is Wildly Overstated

#227

Post by mrkeen »

wrsh07 wrote: post #179

Pretty good takes here in the comments (shout out to references to "pit of success") There are two things worth mentioning, though. 1) the best pragmatic programming recommendation is "semantic compression" by Muratori [1]. Incidentally, I find it to be an effective "takedown" of the sort of dogmatic oop that anyone criticizing oop is criticizing 2) Muratori might disagree with this, but for me the whole point of a n…

> If you need a new invariant, you make a new type.

Agreed, but is that OO?

From [2]:

> Class invariants are established during construction and constantly maintained between calls to public methods. Code within functions may break invariants as long as the invariants are restored before a public function ends.

That just sounds like a race condition with extra steps.

Re: The Case Against OOP Is Wildly Overstated

#228

Post by mrkeen »

jayd16 wrote: post #68
tempodox wrote: post #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.

Calling mutability an OOP issue doesn't make sense to me. You could certainly have immutable objects. You can event have immutable object inheritance. Maybe you just want a language where fields are immutable by default. If you're just passing around raw structs or arrays, it's way harder to manage blocks of data.

> If you're just passing around raw structs or arrays, it's way harder to manage blocks of data.

This isn't an OOP issue either.

Re: The Case Against OOP Is Wildly Overstated

#229

Post by kryth »

wvenable wrote: post #159
drummer wrote: post #111

OOP has served me well. It is a powerful concept. Problem is that people can misuse and abuse things.

It's the most successful programming paradigm in history. I feel like being anti-OOP is like being anti-vax. It's so successful and ubiquitous that it's success becomes invisible and so people only focus on the failures or misuse. Complaining about OOP requires an entire object-oriented software stack to post your argument.

That doesn't make any sense. Being an anti-vaxxer is simply stupid, proven by real numbers and repeated experiments. Meanwhile, there are a lot of fair criticisms to OOP. Of course, a lot of them arise due to the fact that the skill floor for software development is quite low nowadays, but then again if we were all that smart, we'd just write C and C++ at the speed of light for everything. P.S: Rewriting hackernews in a functional stack is trivial

Re: The Case Against OOP Is Wildly Overstated

#230

Post by grawprog »

I've never really gotten the hate towards OOP. It's always logically made sense to me. It follows along the path of abstraction and encapsulation computers had been moving steadily towards. It just takes the concept of a function, packages it together with some kind of data, keeps the internal workings separate from the rest of the program and allows one to reuse or extend those small pieces.

It may not be the best way of abstracting above procedural programming, it's not suitable for everything, it's easy to use poorly, but it's there and it does have benefits and can exist peacefully along side other paradigms.

Post reply on HN