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

251–260 of 557 posts

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

#251

Post by qsdf38100 »

dwohnitmok wrote: post #156
agency wrote: post #70

Earlier quoted context omitted.

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

I enjoyed the talk and agree with it in many ways, but perhaps a contrarian stance will stimulate some interesting discussion. Here's the steelman I can think of against that talk. Hickey's fundamental contention is that whether something is easy is an extrinsic property whereas whether something is simple is an intrinsic property. Whether something is easy is dictated often by whether it is familiar, whereas simplic…

This concept of "used to" vs "understand" reminds me of an interview with Feynman where IIRC he explains how can magnetism work at a distance to a layman person. He discusses about the "why" questions and how you keep getting deeper and deeper each time you ask "why". He concludes that his explanations won’t be satisfying for the other person, saying "I can’t explain this to you in terms you are more familiar with". I thought it was interesting and related. I’ll try to find that video.

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

#252

Post by vikingcaffiene »

thangalin wrote: post #246

The PersonnelRecord isn't OOP and exhibits a widespread misunderstanding: class PersonnelRecord { public: char* employeeName() const; int employeeSocialSecurityNumber() const; char* employeeDepartment() const; protected: char name[100]; int socialSecurityNumber; char department[10]; float salary; } As written, PersonnelRecord class will inevitably lead to code duplication, tightly coupled classes, and other maintaina…

I dunno man... I think that giving an entity the ability to perform operations upon itself and thereby changing it, looks neat in these examples but scales poorly in a sufficiently commplex codebase. You could express exactly the same thing but get a lot more bullet proof code if you separate out the thing doing the action from the thing you are acting upon. You could have the thing doing the action return the updated version of the thing you wanted to do said operation upon and its unambiguous what has happened. So something like (psuedocode):

    transferredEmployee = employeeService.transfer(employee, department);
IMO this forces a certain style of coding that ages better and requires keeping less stuff in your head.

My two cents. Have a good one!

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

#253

Post by 7steps2much »

zozbot234 wrote: post #123
astrange wrote: post #43

Earlier quoted context omitted.

> The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though It seems that that's called a state machine, and OOP objects should come with state charts, but they don't. > and this is where newer PL formalisms like "homotopy types" might end up being quite helpful. PL research would actually get adopted if they didn't insist on using the worst possible names for everyt…

> if they didn't insist on using the worst possible names for everything If the alternative is stuff like "FactoryFactoryFactory", I'm not sure that's better.

It might not be better, but at least i don't need a dictionary to understand what it is all about, I just need to read it again and sort out the words in my head.

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

#254

Post by seanmcdirmid »

ummonk wrote: post #176
seanmcdirmid wrote: post #169

Earlier quoted context omitted.

If the state is encapsulated somewhere else, why is it no longer OOP? I don’t think Alan Kay would say that having each object simply be a handle into a table of values meant they could no longer be called objects. Heck, if we take the FactoryFactory example as being the bad thing about OOP, and consider that this comes from the GoF design pattern book, there is already a pattern in that book that closely resembles r…

Encapsulation in OOP terms means the state is encapsulated with the logic that fetches / mutates it. ECS explicitly is designed to do the opposite. It’s really that simple. The issue isn’t about how you store the objects but about whether the framework logically encapsulates object data with its associated logic.

> Encapsulation in OOP terms means the state is encapsulated with the logic that fetches / mutates it.

No it doesn't. There are plenty of examples in OO where that isn't true or no physics engine that's been build in the last two decades would work at all. The only core thing needed for OO is that objects have unique identities that then enable a notion of associated state at all. A pure system would not allow for an unbounded number of unique identities at all, you would not really be able to talk about objects at all (or entities or whatever object synonym is preferred).

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

#255

Post by taeric »

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…

Hot take: OO is more powerful when you embrace stateful objects. As long as you are dealing with stateless objects, many other techniques have plenty of advantages.

But, consider, OO grew in a time when the likes of Logo was strong. How do you draw a square in Logo? Usually, some form of:

    pen down
    repeat 4
        straight 10
        right 90 degrees
But this /only/ works if you keep track of the state of the system in your mind, when your are figuring it out. Which, works really well if you are being taught that your program doesn't exist in and of itself, but to manipulate something else.

Functional advocates lose many learners because they don't allow that writing a local function can be done with the more global state in mind.

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

#256

Post by seanmcdirmid »

sirwhinesalot wrote: post #190
seanmcdirmid wrote: post #162

Earlier quoted context omitted.

There is nothing wrong with ontological reasoning. A cat is a feline, how you express that relationship, or if it is even worth expressing, is another matter. We also learned “Cat(x) :- Feline(x)”, but never used that either (and no one ever derides the use of predicate logic in programming). I think we spent most of our smalltalk time covering metaobjects (I did my CS program before Java took over).

The problem with the OO style taxonomy is that doesn't just model the taxonomy but it also structures your code, that's usually where the problem is, and it leads to issues like what is the proper superclass: Square or Rectangle. A square is a kind of rectangle but the "API" of a Square is more restrictive than that of a Rectangle (where both width and height can change independently). I've seen this issue discussed…

If the square and rectangles are not mutable, you can indeed treat a square as a rectangle (however you want to express that type). If they are mutable, then a square is of course not a rectangle.

In OOP systems that support predicate-style dynamic inheritance, rectangles pick up the square trait only when their width is equal to their height. We don't talk about such systems very much today (JavaScript does not have a notion of type, and updating an object's type is a mutable operation rather than one driven by a rule), but there were experimental systems from the 90s that looked at this.

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

#257

Post by adgjlsfhk1 »

ummonk wrote: post #232
kloch wrote: post #177

Earlier quoted context omitted.

> Performance approaching that of statically-typed languages like C I might have to give this a try. Is there any language other than assembly that can beat the performance of C?

Other zero-abstraction languages like Rust and Ada have comparable performance to C/C++. Fortran in particular, which has a lot of high performance code written in it, is sometimes faster than C due to optimization assumptions the compiler can make about Fortran code that it can’t about C code. Julia can be slower than these languages due to having a garbage collector and not being a statically compiled zero abstract…

GC overhead only happens if you allocate. Julia makes it really easy to not allocate. Also 1.8 has some features coming that are able to delete some allocations if the data doesn't leak through escape analysis.

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

#258

Post by creakingstairs »

ctxc wrote: post #130
zozbot234 wrote: post #20

This is basically a survey of a bunch of posts, and doesn't do much to provide a consistent critique. Regardless, the true weak point of OOP is arguably implementation inheritance, which just doesn't leave you with a consistent semantics that's open to extension and changes in the basic/derived classes (that is, the well-known "fragile base class" problem is still a showstopper). But that has always been a pretty ad-…

I still don't understand why it's bad! Feels like spaghetti sentences tied together as a single article. Why is OOP so bad, anybody? With scenarios, code samples or alternate implementations?

I think it’s hard to explain it because the very definition of OOP varies per person. Often people who hates it worked with a codebase that took some OOP principles to the extreme. E.g. I worked in a code base with extreme levels of abstraction where literally everything is a class.

That said, any principle including FP, taken to an extreme can produce a very tiring codebase (I’m guilty of doing this :p). So its not really OOP’s fault

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

#259

Post by taeric »

lostcolony wrote: post #19
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 think in a lot of ways you're correct. FP and imperative code tends to makes state explicit; OOP hides state. The latter MAY make things "easy"; it never makes it simple.

To continue my hot take from earlier, OO wasn't supposed to "hide" it anymore than FP was supposed to. Rather, OO was supposed to be about changing the metaphor of the program as you are writing it.

This is most easily seen if you consider a TON of the domain specific languages out there. Logo, PostScript, DVI, GCode, etc. Many of these are "move to X" "put down pen", "move to Y", "pick up pen", etc. Very imperative and how you would talk to someone on how to do something.

So, if your objects give meaningful verbs to control the state that they maintain, it works rather naturally to reduce the code that you have.

Now, most OO today, that I see, embraced objects as records. And goes out of its way to not encode any language of behavior in the code they let you write. But, I don't think that is enough of an argument to say that abstracting some active objects into an OO paradigm is a waste and can never help.

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

#260

Post by karmasimida »

djmetzle wrote: post #225

Meh. Is this a hot debate still? No mention of Ruby or smalltalk in this post, which i think of as "true" OO languages, down to the runtime. The ruby object model has its merits! Sandi Metz's POODR is a fantastic intro into OO _and_ a compositional approach to design. FP vs OO is always a false dichotomy for sure. Actors and messaging appear in FP languages. Inheritance surely has nothing to do with OO. Inheritance m…

It is really weird in 2020 we are still seeing those largely ideological essays against OOP.

The solution is simple, there are tons of languages to use today in a single service/application. Just create your own and put it on the market for validation, if OOP or not is really at the center of productivity then it will be addressed.

Otherwise, I really don't understand the point of such rant posts, feels like marketing and personal flexing.

Post reply on HN