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

81–90 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#81

Post by dclusin »

beaker52 wrote: post #70
Rickasaurus wrote: post #31

Earlier quoted context omitted.

The term we like to use is "the pit of success". It shouldn't be hard to do it the right way.

"The pit of success" is a great guiding principle when it comes to the design of codebases. Forget about "design patterns" and just focus on _how do I allow developers to focus on creating things that are adding value, rather than faffing around with extraneous things_. I can't tell you how many times I've seen a project go full onion-pattern with a web service that basically just recieves HTTP requests and makes a f…

For large interwoven software systems this complexity seen in the form of service layers, directory services, distributed quorums, etc. is often necessary to achieve availability guarantees. I think that the problem is that engineers are over eager to design these sorts of things and implement them before they're actually necessary. And they do it badly and make life shitty in the process because they still don't fully understand the requirements for such a system. OOP just happens to be the language feature they use to make a mess. It would still be no fun even if they used a straight procedural language like C.

Re: The Case Against OOP Is Wildly Overstated

#82

Post by winstonewert »

jayd16 wrote: post #66
lgessler wrote: 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.

Objects are essentially structs with namespaces and methods with implicit this params. If you can't have state then you throw structs out too. If you're going this far, you're essentially throwing away typing as well. Are you actually just opposed to private fields?

I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details.

For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's where things go haywire.

Re: The Case Against OOP Is Wildly Overstated

#83

Post by TheOtherHobbes »

michaelcampbell wrote: post #11
mimixco wrote: post #5

Earlier quoted context omitted.

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?

I'm not sure anyone really knows what OOP's original premise is.

There are various legends, and they mostly conflict with each other.

Re: The Case Against OOP Is Wildly Overstated

#84

Post by fennecfoxen »

skrtskrt wrote: 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…

> As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks.

Once upon a time I worked with a lovely Perl system (!) (yes! Perl!) that used Rose::DB. The main parts of Rose weren't really special in any particular way; the part that was good was that you were provided with rather effective tools for running your own raw SQL queries if you needed to.

Of course the bigger problem with ORMs in OOP isn't raw SQL management. It's the fact that the naive approach to OOP and the approach all the frameworks give programmers looks like "active record pattern" and "fat models". The active record instances can be found all over your code, usually leaking some encapsulation violation wherever they're used, and the fatness of the model usually means that the models also accumulate various concerns from parts of the app that don't belong on the models. Many programmers who approached OOP in an ad-hoc manner aren't even aware of patterns like "entity-component-system" and sometimes have strange ideas of what you're supposed to call a "service".

> I have never seen any good come from more than one layer of inheritance.

Good OOP is compositional and may have a lot of "has-a-strategy" and "implements-an-interface" patterns but usually only a very few "inherits-from" patterns. OOP tools like strongly-typed systems are there to bring you clarity and safety as you move data from your "query XYZs", "plan some XYZ operations", "execute XYZ operations", and the actual system interfaces to perform the operations.

Re: The Case Against OOP Is Wildly Overstated

#85

Post by jayd16 »

JackMorgan wrote: post #77
jayd16 wrote: post #66

Earlier quoted context omitted.

Objects are essentially structs with namespaces and methods with implicit this params. If you can't have state then you throw structs out too. If you're going this far, you're essentially throwing away typing as well. Are you actually just opposed to private fields?

Separating functions and state has nothing to do with the type system. Otherwise how could you put types on the parameters to static functions? Check out F#, OCaml, or Haskell for plenty of examples of how you can have strong static types without mixing state and functions in a scope together.

>Otherwise how could you put types on the parameters to static functions?

Object methods are just sugar for this, so whats the difference to you? When you say "separate" do you mean you just want it in different files? Different curly braces? Different namespaces?

Is it inheritance and virtual functions?

Re: The Case Against OOP Is Wildly Overstated

#86

Post by agumonkey »

lgessler wrote: 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.

OOP was a (too) big response after an era of semi-wildness.. I believe nobody mastered the whole cake and it was rarely applied fully. Most of it is simply mental logistics convenience (most related methods are one dot away) and of syntax. car_start(&car) is noisy; car.start() a tiny bit less so.

Re: The Case Against OOP Is Wildly Overstated

#87

Post by jdmoreira »

I wish I could read this but it’s hosted in Medium and no, I won’t create an account.

Seriously why does anyone even publishes there?

In fact I'm already biased against the author just because of his choice. If he can’t even bother not using Medium can I really trust he spent the time to think through what he wrote?

Re: The Case Against OOP Is Wildly Overstated

#88

Post by dsun179 »

jdmoreira wrote: post #87

I wish I could read this but it’s hosted in Medium and no, I won’t create an account. Seriously why does anyone even publishes there? In fact I'm already biased against the author just because of his choice. If he can’t even bother not using Medium can I really trust he spent the time to think through what he wrote?

I think we should publish these articles on github as readme. Then people can even add stuff and fix typos.

Re: The Case Against OOP Is Wildly Overstated

#89

Post by jayd16 »

winstonewert wrote: post #82
jayd16 wrote: post #66

Earlier quoted context omitted.

Objects are essentially structs with namespaces and methods with implicit this params. If you can't have state then you throw structs out too. If you're going this far, you're essentially throwing away typing as well. Are you actually just opposed to private fields?

I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's…

Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation.

Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?

Re: The Case Against OOP Is Wildly Overstated

#90

Post by vsareto »

beaker52 wrote: post #70
Rickasaurus wrote: post #31

Earlier quoted context omitted.

The term we like to use is "the pit of success". It shouldn't be hard to do it the right way.

"The pit of success" is a great guiding principle when it comes to the design of codebases. Forget about "design patterns" and just focus on _how do I allow developers to focus on creating things that are adding value, rather than faffing around with extraneous things_. I can't tell you how many times I've seen a project go full onion-pattern with a web service that basically just recieves HTTP requests and makes a f…

OOP is conducive to premature optimizations. It hints for you to find the right abstraction for future problems, because that's where the productivity gain supposedly is. Instead of rebuilding cars from scratch every time (in the future), I have an interface.

Learning it starts to train you to look for these opportunities, and eventually you start thinking "what if this class becomes a foundational class? I want everyone working on it to have a great time. I don't like being cursed out for not predicting the obvious future", and so now there's a bunch of onion-y stuff added.

Post reply on HN