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

391–400 of 557 posts

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

#391

Post by scrubs »

kinjba11 wrote: post #352
jay_kyburz wrote: post #304

Earlier quoted context omitted.

This is what I don't understand about the mutable vs immutable, my functions only exist to mutate state.

> only exist to mutate state Which part of the state, and when? Is this your program? // change anything, anywhere, in the entire database, the biggest state execute_sql(user_input) You might want controls around that state so not anyone can change it. It might be read only for some users - that is, immutable. Is this your program? log_to_database(financial_event for $5.00) You probably want your financial logs to be…

Try instead this for pure function: thread safe radix trie supporting ins, del, find. Purpose exclude blacklisted ip addresses. Go!

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

#392

Post by sirwhinesalot »

q-base wrote: post #337
sirwhinesalot wrote: post #153

Earlier quoted context omitted.

I like to call that style "modeling a taxonomy of the world". Even real-world carefully studied taxonomies change all the time, good luck adapting your code base when an employee is also a customer. It was a crap style from the very beginning. Smalltalk style OOP has its own issues, but there's lots of good aspects to it and you really have to experience Smalltalk as a complete system to really get it, it's nothing l…

Would you mind explaining this part a little more - I do not get the difference between a Customer class and a customer as a unique entity represented by an ID? "That said, best thing you can learn in your programming career is to get rid of "Customer" classes (or whatever the equivalent is for your particular problem). A customer is a unique entity represented by an ID, a private key if you will, which links data in…

Hi q-base, it all comes down to the single responsibility principle. What is the single responsibility of the Customer class?

What methods should it have? What does a Customer do exactly? Or is it just a POD which simply stores customer data? If so which data? Does it mix authentication information with the user's purchase history? Maybe not that but what about the user's little Avatar in the UI?

The answer is none of the above, the single responsibility of the Customer class is to identify a user, that's it. In the end that's just a number, no need for a class. The purchase history of a user is only relevant to the system that manages the purchase history. The avatar is only relevant to the UI. The authentication information to the authentication service.

A Customer is not in and of itself an "entity" of some sort with associated behavior in the OO sense. But you see this all the time with companies trying to model these taxonomies of their business as class hierarchies.

It's an unhelpful practice that imposes a structure on your code that's not relevant in a any way to the actual functionality of your software.

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

#393

Post by rawoke083600 »

kinjba11 wrote: post #352
jay_kyburz wrote: post #304

Earlier quoted context omitted.

This is what I don't understand about the mutable vs immutable, my functions only exist to mutate state.

> only exist to mutate state Which part of the state, and when? Is this your program? // change anything, anywhere, in the entire database, the biggest state execute_sql(user_input) You might want controls around that state so not anyone can change it. It might be read only for some users - that is, immutable. Is this your program? log_to_database(financial_event for $5.00) You probably want your financial logs to be…

>Is this your program?

You sir - should write flyers and product-copy :)

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

#394

Post by rawoke083600 »

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++,…

I like your "bullet points" and agree with them all.

Wat are your thoughts on (super simplified example):

* 1 state-var with 3 values ?

* 2 state-vars with 2 values each ?

Sometimes I steer my design too much to first example and then other times to the last example. Both extremes can make things ugly

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

#395

Post by simongray »

butwhywhyoh wrote: post #166
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…

The problem I have with talks like this is that they sound fantastic on the surface. They almost sound self-evident! "Duh! I want to make simple things, not easy things! That was great!" But where are the examples? Not a single example of something easy versus simple, or how something "easy" would resist change or be harder to debug. All of these concepts sound fantastic until you begin to write code. How do I apply…

The presenter is Rich Hickey. He is the guy who created Clojure. He basically designed the language around this principle (it is a very opiniated language). If you want examples, look at Clojure and its ecosystem where the ideas of Rich Hickey are held in high regard.

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

#396

Post by scrubs »

zozbot234 wrote: post #27
lostcolony wrote: post #19

Earlier quoted context omitted.

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.

"Hiding" state is necessary to endow it with well-defined invariants. This can be done in many FP languages, too. The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though, and this is where newer PL formalisms like "homotopy types" might end up being quite helpful.

Absolutely. Why make const char * data private in a string class otherwise? I have know it's in a valid state so I can get it to the next valid state when caller runs an operation on it.

But then a lot of proving (small p prove) an object in c++ is in a valid state amounts to hoare predicates and other spark-ada like expressions.

Certainly FP could do same and like c++ define that away when callers and callees think undefined behavior is gone?

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

#397

Post by rawoke083600 »

reificator wrote: post #117
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…

> This is why simulations like say someone making a game or simcity with like relatively independent entities that map to something in real life use OOP. I don't think this is the case, or at least it hasn't been for quite awhile. Any gamedev I've known in the last decade or so would reach for an ECS[0] if they wanted to clone SimCity, in other words they would design it somewhat like a normalized database. Each char…

Even if you not a game-dev. I urge you to look into ECS just as a mental-exercise. There are some excellent YouTube talks on the subjects.

Many of us are 'stucked' wring the same old CRUD-Variation-Apps stuff. Learning about ECS is a great way to get those "original-programming-excitement-juices" flowing :)

The gaming industry is renowned for some fantastic programming solutions. To ekt out every bit of performance.

Anywhoo - makes for a nice change to arguing with colleagues over ORMs, Fat-Vs-Thing models :P

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

#398

Post by Enhex »

people who hate "OOP" are usually ones that fail to understand how to use some language features. prime example is "Circle–ellipse problem" which demonstrates how people fail to realize inheritance is about code reuse and not about representing hierarchies of abstract ideas (and i wonder where they got that wrong info from, perhaps they extrapolated it from the name "inheritance"?).

same goes for all the other language features.

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

#399

Post by SebastianKra »

joeldo wrote: post #127
ianbicking wrote: post #63

Earlier quoted context omitted.

I assume you are talking about React. It started fairly OOP. Now it's... something else? It's not functional. IMHO hooks and effects are a crazy form of OOP. It's like some weird dynamic scope data definition.

I'm not exactly sure how hooks are related to OOP. Their design was inspired by 'Algebraic Effects' which are more functional in nature than OO. This gives a good breakdown: https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Isn't this basically the same tradeoff as Contexts vs Prop-Drilling?

You could achieve the same effects by passing down callbacks.

I thought the reason why this is good for Errors, Themes and Loading (Suspense), is because they're so common, that you can always expect someone up in the hierarchy to consider it, and therefore sacrifice some type safety for less verbosity.

The article mentions that "usually the fact that a function can perform an effect would be encoded into its type signature", which is why I don't understand the need in this example.

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

#400

Post by rawoke083600 »

seanmcdirmid wrote: post #151
ummonk wrote: post #147

Earlier quoted context omitted.

I’m happy to be corrected as I’ve only really dabbled with Indie game development on and off but my general impression is that the paradigms have gone procedural -> object oriented -> ECS. For example, Unity is designed around GameObjects but is now adding building out the DOTS framework stack that’s more of a first party ECS system.

Nobody has ever been able to convince me that these informal object systems (eg ECS) aren’t really just OOP with different extensibility mechanisms and/or a different place to stow away object state (oh, and let’s call the objects entities instead). The only real diversion from objects in games that I’ve seen is the work in Andrew Kennedy’s thesis on FRP for games.

I'm no expert, but here are my 2cents.

One of my "ahhh moments" with ECS was when someone pointed out. The ECS has a very 'strict' boundary on DATA(attributes,entities,components) VS BEHAVIOR (methods,systems,functions).

The 'traditional OOP' usually 'smash/hide/design/encapsulate' these two conflicting powers into one 'Entity'

I think it's 'easier' to write a ball-of-mud in OOP for games, then it is to write ball-of-mud with ECS.

*NOTICE I said 'easier' not 'impossible'

I love the distinctions between BEHAVIOR and DATA, from an organizational point of view. The bigger the whole system is the more value I think a good programmer can get with ECS.

Imagine having to "implement" gravity for 100 different types of 'Objects'. Sure The ECS way would be to have a System(Gravity) that executes the 'same computing' on all entities with a 'MassComponents' and 'PosComponents' for example. The Entity would usually not need to know ANYTHING about Gravity. Sure the OOP way one can inherit but eventually you inherit yourself into a corner (diamond-problem).

My 2cents - YMMY

TL;DR (just squint hard enough)

ECS ~= (Data | Behavior)

OOP ~ (Data + Behavior)

Post reply on HN