The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#271

Post by zaphar » Sat, Aug 01, 2020, 12:25 PM UTC

wvenable wrote: post #251

zaphar wrote: post #247

Earlier quoted context omitted.

Is-a relationships are best handled by interfaces. If you don't have those and only have inheritance then that is the exception I mentioned above. In those cases I would argue that the base class should be composed entirely of abstract methods and the depth of the inheritance hierarchy should be no greater than 1.

If you have something that is something else in almost every way except for one or twos details inheritance is far superior than interfaces. The other benefit of inheritance, that often goes unmentioned, is the ability to fix bugs in other products. I've had to inherit from some library/framework class to fix a bug in that technology -- it might be a rare situation but it's absolutely invaluable to have that option.

I'll have to take your word for it that such things exist but experience so far has taught me that:

1. When I have something that is something else with minor modifications that my and everyone else's lives will almost always be better when if I solve the reuse issues with some composition and the is-a problem with an interface.

2. That when I inherit from a class I don't control to fix a bug in that class the fix is both very fragile and usually very short lived. Either way I created a problem for myself later on down the line.

I don't disagree that sometimes the framework or library you are using give you no other choice than inheritance. In those cases using inheritance is your only and therefore best option. However I don't consider the framework to be better for it. I consider the framework to worse off for it.

Re: The Case Against OOP Is Wildly Overstated

#272

Post by thebruce87m » Sat, Aug 01, 2020, 12:25 PM UTC

correct_horse wrote: post #216

AnimalMuppet wrote: post #149

Earlier quoted context omitted.

I'm not the one you're asking. But... Here's a data structure that represents a bill of materials. It has a list of components, and a total cost, which is the sum of the costs of the components on the list. That's the invariant - that the total cost is the sum of the costs of the components in the list. If it's just a structure, then someone can add or remove a component, and forget to update the total cost, and the…

This is generally accurate, but I want to highlight the awesomeness of opaque structs. In C you can declare a struct in a header file, but not its fields ie struct point;. Then in the corresponding c file you can write out the whole definition ie struct point {x: float; y:float;};. Any code that includes the header can pass pointers to struct point (or pointers to pointers, etc) but can't directly pass points around…

Isn’t this the way C++ operates under the hood, with the “this” pointer hidden?

I love opaque structures, but the one downside in embedded is they can’t be truly opaque since you want to avoid dynamic memory allocation - and therefore the place you instantiate the struct needs to know the size, and therefore members of the struct.

Re: The Case Against OOP Is Wildly Overstated

#273

Post by saurik » Sat, Aug 01, 2020, 12:36 PM UTC

cellularmitosis wrote: post #240

lkrubner wrote: post #93

Earlier quoted context omitted.

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…

Is the problem better than 80% with other paradigms though? Even after controlling for "only smart programmers bother working in less popular paradigms"?

Re: The Case Against OOP Is Wildly Overstated

#274

Post by GordonS » Sat, Aug 01, 2020, 12:53 PM UTC

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…

I enjoyed reading Muratori's blog post you linked to - it's interesting to read the thought processes of a dev who writes so well.

But I don't get how "semantic compression" is any different from the more commonly termed DRY (Don't Repeat Yourself)?

Re: The Case Against OOP Is Wildly Overstated

#275

Post by GordonS » Sat, Aug 01, 2020, 1:00 PM UTC

Something I'd really love to see is a GitHub repo containing different projects written in both an OOP style (e.g. with C# or Java) and an FP style (e.g. with F#, Scala or Python).

F# and Scala also have both OOP and FP features - something else nice to see would be the same project written in both OOP and FP styles in the same language.

Anyone have any links to repos or blog posts along these lines?

Re: The Case Against OOP Is Wildly Overstated

#276

Post by Wilem82 » Sat, Aug 01, 2020, 1:18 PM UTC

wvenable wrote: post #245

kryth wrote: post #229

Earlier quoted context omitted.

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

There are plenty of potential side-effects for vaccines as well. The last time I had one, I had a relatively unpleasant reaction. So I'm not saying that there aren't fair criticisms of object-oriented programming. But "the case against OOP" is not proven by real numbers and repeated experiments. It's the most successful programming paradigm in history. The evidence for the success of OOP is more overwhelming than for…

> But what about the web browser, the GUI environment, the OS kernel?

Firefox is being rewritten in Rust, which is not oop. Linux kernel is in C, which is not oop.

Eclipse SWT, a very succesful java GUI, uses composition over inheritance.

Re: The Case Against OOP Is Wildly Overstated

#277

Post by lloydatkinson » Sat, Aug 01, 2020, 1:22 PM UTC

PaulHoule wrote: post #34

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.

I knew a professor who worked on Density Functional Theory which can be used to derive many of the properties of materials from first principles. (e.g. "Does Iron Conduct Electricity?") This involved running FORTRAN programs on what was then considered a large supercomputer (256 nodes.) Asked what he thought about any programming technique that cost a factor of 2 in performance and he told me it was a non-starter whe…

What’s hadoops equivalent now then?

Re: The Case Against OOP Is Wildly Overstated

#278

Post by garethjrowlands » Sat, Aug 01, 2020, 1:22 PM UTC

mark-r wrote: post #157

addicted44 wrote: post #100

Earlier quoted context omitted.

Eventually data has to be bound to code. Otherwise you'd have apps where you either have functional code running and other apps that are displays of raw data. The engineering question is what layer is it appropriate to do so. Under traditional OOP (your pre functional forward Java/C#/OOP C++), the answer was that code is almost always bound to data. Haskell style functional programming binds code to data at the last…

Yes, it does seem like OOP and functional are on opposite sides of a spectrum. OOP is all about having and controlling state, while functional is about being stateless. I think my own code would benefit from being more functional, but that's hard to do in a OOP infrastructure.

Maybe try to aim for functional core, imperative shell, see https://www.destroyallsoftware.com/screencasts/catalog/funct...

Re: The Case Against OOP Is Wildly Overstated

#279

Post by garethjrowlands » Sat, Aug 01, 2020, 1:40 PM UTC

augustk wrote: post #226

Gibbon1 wrote: post #221

Earlier quoted context omitted.

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.

This paper describes the differences between objects and ADTs, https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...

Re: The Case Against OOP Is Wildly Overstated

#280

Post by garethjrowlands » Sat, Aug 01, 2020, 1:56 PM UTC

meheleventyone wrote: post #231

addicted wrote: post #223

Earlier quoted context omitted.

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.

Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice.

To take an obvious example, you might load a value from a database (company or employees, say), create a new value (with the higher salary, say), then write the new value to the database.