Case against OOP is understated, not overstated (2020) • Hacker News Board

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

#471

Post by edwcross » Fri, Feb 11, 2022, 3:23 PM UTC

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…

C is a pig of a language, so tools that show just how horrible it is, how many bugs are unwittingly written, and how hard it is to make its code safe, could also help pushing people towards better languages.

These tools are more like putting on X-ray glasses and seeing how your fast-food nuggets are made. You will still eat them if you have to, or if you're in a hurry, but you'll be more inclined to take the time to learn cooking, so you can eat healthier food later.

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

#472

Post by agumonkey » Fri, Feb 11, 2022, 3:28 PM UTC

wackro wrote: post #449

agumonkey wrote: post #417

Earlier quoted context omitted.

But even factories and all these terms are very vacuous and only present because objects are giving bad solutions.

I put it to you that the OOP concept of a factory exists because in OOP your factory is often (though not always) a type, and types tend to need names. In e.g. FP there are no objects and therefore no instantiation but you can separate this kind of logic all the same, except you wouldn't call it anything, or would name it like any other function. For the record I've been doing mainly OOP and have dabbled in F# so I'm…

That's the whole point. OO gives a class as base, forcing you to reextract limited instanciation logic into another thing, when it's just functions from a to b. And people get to waste time on this.

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

#473

Post by agumonkey » Fri, Feb 11, 2022, 3:29 PM UTC

projektfu wrote: post #462

agumonkey wrote: post #417

Earlier quoted context omitted.

But even factories and all these terms are very vacuous and only present because objects are giving bad solutions.

Factories really exist because classes are not programmable in many popular OO languages as they are in Smalltalk. Languages inspired by C++ (Java, C#) tend to have factories. Microsoft used the unfortunate term "ClassFactory" in COM/OLE when they really meant one or the other, as it is a factory of objects just like a Smalltalk class. Other OO languages don't have lots of explicit factories. I'm thinking Objective-C…

Fair point I limited my view onto java. Other systems have various degrees of freedom.

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

#474

Post by eternityforest » Fri, Feb 11, 2022, 3:36 PM UTC

Whenever I hear complaints about a popular programming method, I have some real doubts. Modern software gets better every year.

There may be better ways, but what we have works.

I don't know if the modern world would be possible without OOP. If the only language in the world was Haskell, C, and SQL.... would I have actually learned them, or would I have chosen a different career? Would there be enough devs to have as much software as we do now?

It's hard to tell, because almost everything big is written using OOP. Few things on the scale of LibreOffice or Blink are pure functional.

And Java seems to work exceptionally well for large scale projects.

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

#475

Post by jshen » Fri, Feb 11, 2022, 3:42 PM UTC

rbanffy wrote: post #431

jshen wrote: post #188

Earlier quoted context omitted.

I don’t see much difference between some_state.do_stuff() do_stuff(some_state)

The second one scares me. It implies some_state is mutated (or not, we may just be logging something) by the do_stuff function while the first makes it very clear that some_state is in charge of doing stuff and that the implementation is aware of how some_state is implemented itself. OTOH, the second one would be much better (and imply immutability) if it were written as new_state = do_stuff(some_state) But it'd also…

Immutability is independent of whether something is a method call vs a function call.

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

#476

Post by cowl » Fri, Feb 11, 2022, 4:04 PM UTC

rbanffy wrote: post #431

jshen wrote: post #188

Earlier quoted context omitted.

I don’t see much difference between some_state.do_stuff() do_stuff(some_state)

The second one scares me. It implies some_state is mutated (or not, we may just be logging something) by the do_stuff function while the first makes it very clear that some_state is in charge of doing stuff and that the implementation is aware of how some_state is implemented itself. OTOH, the second one would be much better (and imply immutability) if it were written as new_state = do_stuff(some_state) But it'd also…

This is a symtom of seeing everything with the OOP and state glasses.

let's have do_stuff=square and some_state=2.

What does square(2) imply?

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

#477

Post by baryphonic » Fri, Feb 11, 2022, 4:10 PM UTC

jcelerier wrote: post #358

baryphonic wrote: post #283

Earlier quoted context omitted.

If you want functioning, robust, maintainable software (or even better, software that doesn't require maintenance), then spend a long time modeling the problem domain. Build it as a system of types, a protocol, perhaps even a language (or at least an AST with semantics). Prove things about this model, particularly some useful things about soundness, consistency and (in)completeness. Learn all the funky symbols people…

By the time you're 20% in that process your competitor has already overtook the market.

To quote Thiel, "competition is for losers."

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

#478

Post by ajuc » Fri, Feb 11, 2022, 4:19 PM UTC

hardolaf wrote: post #464

ajuc wrote: post #336

Earlier quoted context omitted.

This is true, and another thing about state is also true - relational databases are much better suited to handle state cleanly and to minimize the amount of it than programming languages (except maybe prolog). Especially OOP languages are bad at state minimalization. For example there's no commonly used equivalent to normal forms in oo. There are no indexes and no materialized views. The funny effect is - if you want…

People also moved away from that paradigm because databases are slow. I work in the world of optimizing TLP level communications over PCI-e buses. To me, a database access is already in the world of "why bother?".

We moved from

    DB  Front end

to

    DB  APP SERVER  FRONT END

I don't think it's any faster :)

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

#479

Post by andi999 » Fri, Feb 11, 2022, 4:36 PM UTC

mujina93 wrote: post #365

usrusr wrote: post #96

Earlier quoted context omitted.

That time part is what you are wrestling with when you are battling with state. So it's natural to think about it that way. But there's also this somewhat dumbed down version of the argument: every piece of state a method reads is like an additional function argument and every state it writes an additional return value. What a mess.

This made me think: if we wrote object oriented code methods where all the members that we access are passed explicitly as parameters, as well as all the members that we modify (as out references), then we at least would immediately identify the real complexity of some methods! I'll try to do this, I'm curious to see how that would look like.

At some point you get too many parameters, so you pass a struct, which basically means that struct turned into an object. (one interesting difference is that you can pass more than one different struct to that function which is the equivalent of subclassing; but with more permutations possible. Thats actually interesting).

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

#480

Post by sunny3 » Fri, Feb 11, 2022, 4:39 PM UTC

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…

My experience with the book and its patterns has been that there's an issue and some developers recognize that it could be best resolved with x, y, or z pattern. Then the developers go to extreme length to make sure the implementation adhere to the the 'principles' or 'spirits' of those patterns, so much so that it creates unnecessary complexity (e.g., unneeded layers of abstraction) and friction in other components (to accommodate the 'purity' of that implementation). What's worse, it's very difficult to challenge such implementation in code reviews, since it's originated by GOF, which automatically makes it legitimate. The worst part, though, is that you have to maintain the implementation, any deviation from those patterns is seen as corner-cutting.