The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#231

Post by meheleventyone » Fri, Jul 31, 2020, 9:19 PM UTC

addicted wrote: post #223

meheleventyone wrote: post #152

Earlier quoted context omitted.

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 fu…

But now you have a stale data problem.

Re: The Case Against OOP Is Wildly Overstated

#232

Post by mypalmike » Fri, Jul 31, 2020, 9:21 PM UTC

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.

The software I write is provably correct because it never changes the state of anything.

Re: The Case Against OOP Is Wildly Overstated

#233

Post by zbentley » Fri, Jul 31, 2020, 9:36 PM UTC

mnm1 wrote: post #133

skrtskrt wrote: post #69

Earlier quoted context omitted.

Of course the biggest gain of ORMs is initial dev speed. If you're going to stand up a business in a week or a month, Django ORM and its migrations are going to get you a pretty darn good solution without spending hours and hours thinking about your RDB design and handling many-to-many relationships "by hand".

Yeah, why spend hours on the most important part of the application and likely the most important part of the business when you can gloss over with with an ORM and not worry about designing the database until it comes back to bite you in the ass when you can no longer grow your business because of the incredibly stupid thing you did which is not designing your database. Frankly, those businesses deserve to fail if th…

I suppose they deserve the same fate if they didn't get security right from day 1? Or accessibility? Or monitoring? Analytics? GDPR compliance? Etc.?

Businesses are confronted with different problems at different times. Insisting that everything be solved/designed perfectly up front is silly.

Re: The Case Against OOP Is Wildly Overstated

#234

Post by mrkeen » Fri, Jul 31, 2020, 9:41 PM UTC

brundolf wrote: post #225

mrkeen wrote: post #224

Earlier quoted context omitted.

> 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 varia…

I'm saying you can have private mutable state if you stick to method variables. If you take a method variable and promote it to a field (private or not), or return it via a public method, you have made it more public - that's what I meant by "The opposite of private/encapsulated".

Re: The Case Against OOP Is Wildly Overstated

#235

Post by Waterluvian » Fri, Jul 31, 2020, 9:43 PM UTC

FWIW I’ve been a python and javascript dev for a long time. I’ve spent this year learning Rust and I’m kind of in love with the whole “it’s just a struct and here are some associated functions” thing. It feels so simple and clear.

I also really liked C#’s “single inheritance plus interfaces”. That was also an eye opening moment.

Re: The Case Against OOP Is Wildly Overstated

#236

Post by MasonOfSpoons » Fri, Jul 31, 2020, 9:46 PM UTC

TheOtherHobbes wrote: post #83

michaelcampbell wrote: post #11

Earlier quoted context omitted.

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.

It feels a bit like a rhetorical device to discuss OOP in any context other than the version of Java that's currently in widest usage.

Re: The Case Against OOP Is Wildly Overstated

#237

Post by devonkim » Fri, Jul 31, 2020, 9:58 PM UTC

nfw2 wrote: post #200

jmnicolas wrote: post #168

Since I accepted I was no Einstein I embraced the KISS principle. My code became simpler, easier to understand. Of course it wouldn't get the approval of any software architect or any design pattern fanatic, but I can take any code I wrote 3 years ago, understand it on the fly and edit it with confidence. There are few bugs and they're never a nightmare to find. Now if I have to modify the code I was writing before m…

Einstein himself would approve this philosophy. As he once said, "Everything should be made as simple as possible, but no simpler." Still, finding the simplest-possible solution to complex problems is often challenging in itself, especially considering what is "simple" or "intuitive" can be highly subjective. Engineers are often uncomfortable thinking about these problems because the domain is shifted somewhat away f…

The problem with "simple" is precisely the problem of removing what is not necessary. In most commercial software design, we tend toward making designs so flexible we make them tougher to reason about than necessary. One of the other problems in software is that software that is good is also the code that is easiest to understand and therefore replace. This doesn't happen so much with things like houses evidently.

Re: The Case Against OOP Is Wildly Overstated

#238

Post by fish45 » Fri, Jul 31, 2020, 9:59 PM UTC

tgflynn wrote: post #41

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.

So what is your preferred solution for programs that intrinsically need to deal with a lot of state ? Global variables ? I used to see that type of approach in some complex Fortran simulation programs where every function referenced a huge common block. I really don't think that leads to easier to manage solutions.

ECS architecture is IMO very frictionless no matter how much state you have

Re: The Case Against OOP Is Wildly Overstated

#239

Post by mypalmike » Fri, Jul 31, 2020, 10:01 PM UTC

commandlinefan wrote: post #197

antonvs wrote: post #151

Earlier quoted context omitted.

That's basically a hand-rolled implementation of a state monad that supports real mutability. The Haskell equivalent is the ST monad. While it's possible to do this kind of thing, it's busywork that properly designed programming languages are perfectly capable of handling well on our behalf.

I had the same thought: he's doing OOP without using the "class" keyword. Well-written C code is actually very object-oriented this way, it just doesn't take advantage of the syntactic sugar of C++.

This is a common misunderstanding. Structural programming like this is clearly similar to what we think of as OO. But it existed before OO and is still heavily practiced in non-OO languages such as C.

The main feature that OO added to this was dynamic function dispatch via inheritance. The specific function that gets called at runtime depends on the type of the struct.

Inheritance has proven powerful but often results in confusing code. The development of interface-based (non-inheritance) dynamic dispatch in COM and Java, and later embraced by Go and Rust, shows that we can get what is arguably the primary benefit of OO with a flat structural approach.

Re: The Case Against OOP Is Wildly Overstated

#240

Post by cellularmitosis » Fri, Jul 31, 2020, 10:13 PM UTC

lkrubner wrote: post #93

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.

I was about to write exactly this. In 2014 I wrote an essay that has been discussed here on Hacker News several times [1]. When I re-read it now, parts of it seem very subtle, parts of it seem to be matters of opinion, but what jumps out is how really dangerous it is to tightly bind data with behavior, especially because this then leads to the problem of initiation (which I devote a lot of time to talking about in th…

Thank you for this. I am so tired of this exchange:

    A: OOP isn't so bad, actually.
    B: But what about all these terrible messes?
    A: Oh, that's not a problem with OOP,
       they're just doing it wrong.

I'm sorry, but when 80% of the industry (and 100% of new grads) are "just doing it wrong", it isn't helpful to no-true-scotsman the critics.

The only way I see out of this endless game of semantics is for someone to canonize the tightrope of practices which are "OOP done right", and then give it a different name.