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

Case against OOP is understated, not overstated (2020)

boxbase.org

Post reply on HN
Print view View original

421–430 of 557 posts

Re: Case against OOP is understated, not overstated (2020)

#421

Post by reificator »

a-dub wrote: post #293
reificator wrote: post #271

Earlier quoted context omitted.

That’s a very good question, because sequencing tends to be the place where implementations vary the most. Usually there will be some way to sort systems into steps and define the order of those steps. Some require you to hardcode the order, others define constraints like “after input” or “before physics” and attempt to solve those constraints, and some let you define groups that can run together and you define the o…

interesting. this is really cool! in the automatic constraint solver variants (which is more interesting to me) are the schedules static (precomputed at compile time) or do they run as a dynamic scheduler of sorts and are the constraints statically checked for deadlock ahead of time? this architecture is exciting!

Compile time would be pretty sweet. I've never looked into it so I don't know for sure.

Don't get too caught up in the hype, it never ends well no matter what the architecture. But it's certainly useful and fun to play with.

Re: Case against OOP is understated, not overstated (2020)

#422

Post by sirwhinesalot »

dragonwriter wrote: post #419
sirwhinesalot wrote: post #389

Earlier quoted context omitted.

The Square vs Rectangle issue is just an example. They shouldn't even be modeled as a hierarchy they should just be simple structs. It's just an example on how OO taxonomies are a silly (and detrimental) exercise.

> The Square vs Rectangle issue is just an example. Yes, it's an example of a problem that has nothing to do with OOP and everything to do with applying model concepts from one domain to a different domain. > They shouldn't even be modeled as a hierarchy they should just be simple structs. Whether they are structs or objects with state and attached methods is an orthogonal concern to whether they form a type heirarch…

We will just have to agree to disagree then, for me the Square vs Rectangle inheritance issue is the simplest possible example of the problem, where trying to model an inheritance hierarchy "the right way" directly impacts the structure of your code in a detrimental way, and the solution is to avoid OOP silliness in its entirety.

Even in the immutable case if you have a Square inherit from Rectangle it still stores 2 separate fields for width and height (that it inherited), which are unnecessary. The only winning move is not to play.

Re: Case against OOP is understated, not overstated (2020)

#423

Post by Lutger »

taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

Your view isn't simplistic, I think a vast majority of developers would agree with it. State, however, is necessary for the purpose of creating useful and in some cases performant programs. Furthermore, in some cases state can make a program quite a bit easier to write and even read.

I think there are much more interesting things to be said about state than just to minimize it. For example, you can limit stateful computations inside a function in such a way that the function itself is still referentially transparent (it behaves as if it wouldn't have state). In this way, you can still do a for-loop, or do a quick-sort on a copy of the input data, without losing the benefits of pure functions. In the D programming language, this can be expressed in the type system.

We need to 'deal with' all the risks that state involve, reducing it is the first thing to do but then there are a lot of other options as well.

Re: Case against OOP is understated, not overstated (2020)

#424

Post by Draiken »

jay_kyburz wrote: post #345
dvt wrote: post #331

Earlier quoted context omitted.

> Ouch, not even unit tests to catch regressions? I also don't like unit tests and very rarely unit test. I think they provide a false sense of security and were invented by corporate software shops to better quantify "units of work" (oh, how many times I've had unit tests assigned to me in tickets!). If you can't formally prove something doesn't break (in your head or with pen & paper or via pseudocode), your code i…

This is probably a bad habit, but I've been writing tests so that I don't have to actually navigate though my app, put it in the correct state, and push a button to see if the feature works or not. Writing the test is just faster.

This is one of the major sources of bugs in my experience. People write unit tests that are perfect and pass, but only pass because you give it exactly the right input to make it pass in the first place.

Then when running the actual app, the data is not exactly like on the unit test and you have bugs.

To cover those scenarios, we use integration/acceptance tests.

So I always come back to the same question: then why should I even bother with unit tests? Especially the unit tests that people normalized (test per class/public method).

You end up with unit tests that are extremely coupled to the implementation, and without proper integration tests, you can't guarantee it will all work anyways. It only works on a bubble.

I believe tests should be much more about the broader behaviors than the implementation details, but TDD and evangelists of today will have you writing tests for every small class you create. I personally still use unit tests from time to time when there are a ton of edge cases on a single behavior that I want to test, but that's the exception not the rule.

By avoiding unit tests, or to put it differently making the units tested larger, you get more space to refactor, less coupling between tests and implementation as well as more meaningful tests.

Somewhere along the way we lost the meaning of "unit" and it became "class/methods", when it was originally supposed to be more at a module level.

Re: Case against OOP is understated, not overstated (2020)

#425

Post by zozbot234 »

hota_mazi wrote: post #306
taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

I used to think that the solution to mutable state was to prohibit it and code with immutable structures all the time, but after a few years of Rust, I think it's the wrong approach. The right way to handle mutable state is not to pretend it doesn't exist but to accept it as a reality of complex systems and to encode its management in the type system of the language. And that's exactly what Rust does. With Rust, I no…

Rust prohibits shared mutable state as part of the basic language (or rather its 'safe' subset), relegating it to special-cased "interior mutability" constructs. This is essentially "as immutable as you can get" in a low-level, systems programming language. (Other languages can thread state mutations explicitly as part of a generally "immutable" design, but that doesn't give you support for the expected low-level features, so instead it's part of the language in Rust.)

Re: Case against OOP is understated, not overstated (2020)

#426

Post by kqr »

psychoslave wrote: post #384

>I find it much easier to formally verify things correct than to test that they're correct. This rise in me the famous joke by Knuth: Beware of bugs in the above code; I have only proved it correct, not tried it. I wonder which tools he uses to prove correctness, and on which language. I know about Frama-C, Coq, and things like that. But I never had the opportunity to use them out of university. On the same topic, in…

In that case I think Knuth referenced proving it by hand, e.g. with Hoare triples.

You could argue that hand proof is useless, but by forcing yourself to go through it in tiny steps you can actually sort out a lot of oversights.

Re: Case against OOP is understated, not overstated (2020)

#427

Post by WA »

ahartmetz wrote: post #371
taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

I have come to the same conclusion. State is the problem. State should be: - minimal (amount and lifetime) - well conceptualized (~= easy to understand the organization) - well named - minimally exposed - coherent by construction (make inconsistency impossible by design of the format or by offering updating functions that ensure the invariants) OOP can actually help with some of these things! I develop mainly in C++,…

All well and good, but where do you put the damn state?

Re: Case against OOP is understated, not overstated (2020)

#428

Post by marcos100 »

_fullpint wrote: post #106
marcos100 wrote: post #75

Earlier quoted context omitted.

What isn't a footgun in the terms that you declared? I believe people dislike OOP because the vast majority of code is written using OOP. If everything were written using data oriented programming or whatever, people would have the same reaction as they have regarding OOP.

>> What isn't a footgun in the terms that you declared? There are definite degrees to this. But something like FP that declares f(x: X) => Y, instead of something like OOP where given context: x: X, y: Y and f() => void (where there is an effect on y) those are massively different scopes of problems. It's not that you cannot do the previous in the latter, but that people -- especially those that are inexperienced and…

So, just to clarify before people think I'm an OOP advocate and it's perfect, I don't, but I think it has it's place.

> There are definite degrees to this. Agree. The question is, does OOP leads to more buggy code? Maybe yes, so we ban OOP? Because that's the sentiment I get whenever someone is against it. In your example, is it ok allocating a new object every time? If you can't afford to do it, what do you do?

> Why do you believe that's the reason why? I think in terms of proportions. For example, if you have 80% of all code written is OOP, chances that you'll find a bad OOP is greater than finding bad code in any other paradigm.

What if people learn programming using FP or DOP? There would be less buggy code? I don't know, but I think in the end, OOP would become the popular choice because, in my opinion, it fits very well the way we think about our world and we would end having this same conversation.

Re: Case against OOP is understated, not overstated (2020)

#429

Post by Diris »

EdwardDiego wrote: post #327

> I'm not going to go there much more because I still don't unit test my stuff. I'm currently not against it. I just don't know about it much. Ouch, not even unit tests to catch regressions? So many of the bugs that I deal with in $BIG_FOSS_PROJECT are regressions where a bug fixed in version X.Y.5 was reintroduced in X.Y+1.0 by someone's cool shiny new feature. And yes, there's a significant lack of unit tests in so…

I've seen multiple people pointing this out, but completely ignoring the next sentence.

> I find it much easier to formally verify things correct than to test that they're correct.

I don't have anything else to say but I wanted to put it here for context.

Re: Case against OOP is understated, not overstated (2020)

#430

Post by zamalek »

wackro wrote: post #240
zamalek wrote: post #206

My issue with OOP is: Design Patterns: Elements of Reusable Object-Oriented Software. I don't take issue with the authors, with their insights, or anything related to the content of the book. It's that the book exists at all: it's a book filled with solutions to imaginary problems. When using a procedural language the first thing you do is start implementing a solution. When using OOP, you first have to solve the ima…

>solutions to imaginary problems This is a fundamental misunderstanding of what patterns are. The GOF book is used to this though. A design pattern is someting that will naturally crop up if you adhere to certain design principles. If you follow a principle of separating instantiation logic from other logic then you will start to see factories. If you combine multiple complex parts of your code into simpler ones then…

That exact sentiment exists deep in my comment history here: I think I used the word "blueprint" if you care enough to fact check that. That is why I said I don't hold issue with the content of the book.

My issue is that the book is useful. It helps solve the artificial complexity introduced by OOP.

Post reply on HN