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

The faster you unlearn OOP, the better for you and your software

dpc.pw

Post reply on HN
Print view View original

11–20 of 252 posts

Re: The faster you unlearn OOP, the better for you and your software

#11

Post by thanatropism »

I'm a simple man. I don't have an advanced education in computer science (I did have a SICP-inspired first course in programming as an undergrad and an algorithms course in grad school using Dasgupta and Kleinberg/Tardos).

Like everyone who's doing stuff with data, I live in Python now. I'm fairly conversant in functional idioms (wrote a monad tutorial when it was all the fashion), but like objects because they're a straightforward way to keep data and code together in a bundle that can be passed around and serialized.

The typical situation for me is machine learning - I could have "fit_to_data" functions that return matrices or otherwise sum/product types (as they called it in Haskell) containing the estimated parameters and "predict_from_param_struct" functions, but having the whole thing in a bundle erases the whole problem of having to remember a weight matrix comes from a logistic classifier and not a linear regressor. That, or use an idiom like

     data LogisticParams a = LogisticP (Matrix a)
(I don't remember Haskell syntax anymore) but I'm not sure how I'm better served by that. The scikit-learn-type idiom where every regressor is expected to have .predict and .fit methods helps me build new regressors while reutilizing all of the scikit-learn cross-validation/hyperparameter search tooling. The idiom above would require me to study the hierarchy of types upwards and whatever advanced features of the language they're using; but even if the scikit-learn team is using features of Python outside my understanding (say, async, or low-level numpy/communication with C libraries) I'm still able to adhere to a convention.

---

That said, have y'all ever heard of Formal Concept Analysis [1]? It seems to me that a lot of the malaise about OOP is that tutorials and examples and maybe even production code (what the hell do I know) are struggling to define ad hoc concept hierarchies -- is it Kitchen.Lights.off() or Lights.off("kitchen")? What scikit-learn (and the universe around it that tries to adhere to the dialect) is simply to embed data (parameters which are derived from data) in code that knows how to use it. No one's trying to decide how TopologicalSpace.MeasurableSpace fits with IntegrableFunctions.ProbabilityMeasures...

[1] https://www.researchgate.net/publication/275540145_Formal_Co...

Re: The faster you unlearn OOP, the better for you and your software

#12

Post by geocar »

adnzzzzZ wrote: post #2

>The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a cl…

> What does the non-OOP solution for this problem look like?

    function hit(player, weapon, monster) {
This is a major problem with single dispatch, a popular OOP implementation choice, but not the only one. Common Lisp and C++ have multiple dispatch, which is a generally accepted solution to this problem.

It seems like a lot of the challenges you're facing has to do with object-oriented design not being a good fit for your problem. Some problems really do organise well into independent actors, maybe the one you're doing isn't one of them?

Re: The faster you unlearn OOP, the better for you and your software

#13

Post by hoorayimhelping »

bvrmn wrote: post #9
eitland wrote: post #6

I read this quickly to see if this was the piece that should convince me. It was not. It is, IMO, a collection of strawmen. People have abused OOP? Yes. But - citing FizzBuzz Enterprise Edition (which is really funny even for us Java/.Net developers because it is so horribly wrong) or writing this - Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to the…

> What probably is true however is that a lot of people should unlearn the OOP they learned in school. Can you provide references for proper OOP?

https://en.wikipedia.org/wiki/SOLID

I wish they would have taught me this in school. Instead, I learned that a cat is an animal, and a car has wheels, and a car is a vehicle. But not what any of these things have to do with one another and how to actually use them.

Re: The faster you unlearn OOP, the better for you and your software

#14

Post by agumonkey »

The problem with OOP is that it became so ubiquitous. Everything had to be OO, millions of hours spent trying to fit everything inside absurd taxonomies.

There's good bits in OO. You can find articles about how parameterizing large `switch` statements into objects can lead to obvious improvements.

My only conclusion is to bet on biodiversity~. I learned so much in relational (db) logic, functional programming, logic programming, stack languages (forth threaded code) etc etc. As soon as your brain sense something useless discard it and find another cool trick/theorem to grok.

Re: The faster you unlearn OOP, the better for you and your software

#15

Post by badminton1 »

Bashing imperative + structured + OOP is valid if you have a viable alternative. That viable alternative is proper namespacing, modularity and functional programming.

If your alternative is another form of spaghetti your problem is not OOP. Your problem is the way you build abstractions.

If your procedures and functions, the foundation of your program, are poorly thought, then you laid a shitty foundation for everything that follows.

Re: The faster you unlearn OOP, the better for you and your software

#16

Post by bvrmn »

hoorayimhelping wrote: post #13
bvrmn wrote: post #9

Earlier quoted context omitted.

> What probably is true however is that a lot of people should unlearn the OOP they learned in school. Can you provide references for proper OOP?

https://en.wikipedia.org/wiki/SOLID I wish they would have taught me this in school. Instead, I learned that a cat is an animal, and a car has wheels, and a car is a vehicle. But not what any of these things have to do with one another and how to actually use them.

I saw many SOLID code bases hard to grasp and maintain because implementation hides data flow. The most evil workers are [D]-purists.

Re: The faster you unlearn OOP, the better for you and your software

#17

Post by Epskampie »

adnzzzzZ wrote: post #5
jdub wrote: post #3

Earlier quoted context omitted.

Entity-Component-System, amusingly explained in this great talk from RustConf. https://www.youtube.com/watch?v=aKLntZcp27M

That solution is more burdensome than OOP

Diagree. Unity works like this, and it’s great for attaching multiple behaviours to an object (i.e. a Player can be Hit, but an Enemy as well). It saves you having to make up a inheritence hierarchy that never seems to work out (Player extends Hittable or something? But it also needa these 10 other behaviours...)

Re: The faster you unlearn OOP, the better for you and your software

#18

Post by [deleted] »

adnzzzzZ wrote: post #2

>The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a cl…

[deleted]

Re: The faster you unlearn OOP, the better for you and your software

#19

Post by [deleted] »

bvrmn wrote: post #16
hoorayimhelping wrote: post #13

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/SOLID I wish they would have taught me this in school. Instead, I learned that a cat is an animal, and a car has wheels, and a car is a vehicle. But not what any of these things have to do with one another and how to actually use them.

I saw many SOLID code bases hard to grasp and maintain because implementation hides data flow. The most evil workers are [D]-purists.

[deleted]

Re: The faster you unlearn OOP, the better for you and your software

#20

Post by abernard1 »

hoorayimhelping wrote: post #13
bvrmn wrote: post #9

Earlier quoted context omitted.

> What probably is true however is that a lot of people should unlearn the OOP they learned in school. Can you provide references for proper OOP?

https://en.wikipedia.org/wiki/SOLID I wish they would have taught me this in school. Instead, I learned that a cat is an animal, and a car has wheels, and a car is a vehicle. But not what any of these things have to do with one another and how to actually use them.

SOLID still doesn't accomplish what the author is criticizing in my opinion.

If I have a SOLID codebase, how do I unroll the object graph to get, say, a hydrated JSON representation of that? (this is the data focus the author is talking about).

I think a person who has maintained an ORM like Hibernate or Rails and wants a simple data projection without having to use their specific tools to do so implicitly understands this pain. A data oriented approach where records are passed through to the business logic as necessary doesn't have this problem.

SOLID still has things like "cat.drivesIn(car)", and so even if the concretions are supposedly hidden behind an abstraction of that interface, the coupling is right there: "drivesIn" irrevocably binds a cat and a car together. In a data oriented, more functional approach, there is a function which happens to know something about cats and cars, and it pulls in two separate records to do its work. This is more of an a la carte approach to building relationships, whereas SOLID makes every consumer potentially need to worry about that because the coupling is in the contract.

Post reply on HN