Ask HN: Do You Miss OOP? | Hacker News Reader

Ask HN: Do You Miss OOP?

7 pointsparentheses11 comments

I've been writing Typescript in a shared repo lately. I've noticed that rather than using classes, many opt for functions and data (which is the "FP way").

I can't help but want OOP for situations where encapsulation is helpful. Creating boundaries around code with similar level of abstraction is useful. The opposite is what we have in Typescript - every file is a bag of functions and data with no clear distinction between parts that may do file IO and business logic.

After re-reading my whining, maybe this is more of a "Tell HN". lol.

View on HN

No, not even remotely.

I've found that OOP has too many footguns and becomes a nightmare to debug. in contrast, I find that e.g traits in Rust (insert equivalent for your language of choice here, I'm aware Rust isn't the only one with it) are a much cleaner fit. I'm not really sure what the official term is, but I refer to it as Composition-based programming. It sits in a perfect middle ground of being object-oriented-ish without letting people go hog wild.

This all said, I find codebases that use only "functions & data" to be very cumbersome as well. We have patterns for encapsulation that have kind of gotten thrown out the window over the years and it's frustrating. Too many of these codebases feel like they have an inadvertent bus factor of one due to the code being so un-encapsulated, and it's one or two people who really know how it all works.

(As a side note, I never got the hate for JS classes - I know they don't behave like true classes in other languages, but I considered that a plus. React was 100x more approachable with them.)

Finally coming back to this and I do agree with a lot of what you say: traits + data types + functions are the right mixture. It gives you immense flexibility, but that comes at a cost of better communication about patterns and practices.

The burden of keeping things organized is largely higher without OOP since OOP does enforce more rigid design constraints and they need satisfying as time goes on. That is often a good thing when delivering features wins over refactoring and cleanups.

Agreed. I recently had to write a package with some quite complex type inference requirements, so I had to resort to classes.

I've since had to issue 17 patches (it's been 3 weeks) even though the package has 100% test coverage.

My initial gut reaction to this was "%$#@ no!", but there are some well reasoned answers here from both camps. The overriding takeaway here is "there is a happy middle ground".

Personally, I have often found that once you try to scale complexity much past the canonical "Student is-a Person" example, it's extremely difficult to avoid violating SOLID principles, and things turn to a big ball of mud pretty quickly.

This is mostly due to inheritance being way overused. Even the initial creators of OOP stated "prefer composition over inheritance" [1], but this seems to get forgotten more often than not. Couple this with Javascript's well known issues with the "this" keyword, and you've got a recipe for disaster.

I avoid the OOP "pillar" of Javascript [2] for these reasons, plus the fact it just isn't required - I never wonder whether the caller has messed with "this", never need to use "bind", etc. etc. "Scoping by function" is a concept I'll blog about sometime soon.

[1] - https://en.wikipedia.org/wiki/Composition_over_inheritance [2] - https://medium.com/javascript-scene/the-two-pillars-of-javas...

I agree, I prefer OOP to much of the spaghetti and 5 layer nested functions that is popular now. This feels like one of those cyclical things that will come back in vogue at some point. People will have trouble maintaining these systems over time, then "discover" OOP and encapsulation, write blog posts about how it is The New Way, etc.

We have some React class components in our system. People who are < 3 years into their career don't like them as they've been told they are complicated and generally considered harmful. Over time, these people tend to come around and realize that class components can be very useful for more complex components.

I feel that functions + data needs some really good linting to keep things clean. The one problem I've never been able to find lints for is "keep related things together" because the implementation of that varies so wildly.

OOP is useful for enterprise. Like it or not, companies think in terms of nouns.

On the other hand, functional programming had the right mathematical idea. No one needed object oriented mathematics, and there's no object oriented physics. (At least, not in any way that's dialectically useful to me in this moment.)

I think the proper place is a healthy middle ground, with capability for both to be mixed and matched as needed.

Functional programming does not prevent you from setting up boundaries between modules and group functions together.

I'm happy with OOP, except for when I have to work with OOP zealots. To get it right you usually do need an overarching philosophy for how to develop. And so every CR becomes a fight over SOLID or DRY principles.

i dont think you've made the point you want. FP isn't just C (procedures and structs) and encapsulation isn't helpful because it enables nothing. Its just a pattern of making certain functions take a secret parameter (this)

you get a clear boundary around useful modules when you have good design. you get clear distinctions with good naming and organization practices.

It never went anywhere for me, so I guess not.

Reply on news.ycombinator.com