Hacker News Reader

Comment by natly | Hacker News Reader

I wish I hadn't bought into the functional programming cult so hard as a younger programmer. I thought it was the future and sacraficed learning and gaining mastery of OOP for that when OOP is a much more widely used and honestly now in hindsight probably better tool in most cases.

View on HN

That surprises me.

My day job is programming in Java, and I use streams and lambdas everywhere. I use very little of OO concepts like inheritance. I try to make my data immutable and write functions and methods without side effects, wherever possible.

Popular recent languages like Go, Rust, and Swift borrow a lot from functional programming paradigms.

I'm curious where you are seeing OOP still going strong.

You brought up the worst part of OOP, inheritance. Which most modern OOP rarely uses. Since the 90s “composition over inheritance” has been a mantra. If you want to build strong arguments, focus on real issues. Not incompetent programmers abusing inheritance or abstract factory factories, because they can write just as awful code in functional programming. There are plenty of actual OOP issues to hate on, but that’s because there is no silver bullet.

> ...inheritance. Which most modern OOP rarely uses

huh?!

What is OOP today in practice if inheritance is dead, as you say, and mutability is out of style, as I've notice in all of the codebases I've worked on since ~2014?

It feels like we're just left with a heavyweight syntax for structs + functions bound to data, which feels like pretty thin gruel.

What are things that are OOP specific (as in not used at all in FP) other than inheritance?

> Since the 90s “composition over inheritance” has been a mantra.

That seems a little early. I think the 90's were still pretty inheritance-centric.

Java only came out in 1996. UML 2.0 was releaeased in 2005.

I'd say the composition over inheritance movement wasn't widespread until the 2000's,

>[Composition over inheritance] is an often-stated principle of OOP, such as in the influential book Design Patterns (1994)

You are absoultely right -- p. 20 "Favor object composition over inheritance", right in the introduction.

I guess my memory was wrong (or I was hanging around the wrong crowd in the 90's.)

What are the real issues in OOP?

The concept of composition has long been the bread and butter of functional programming paradigm since antiquity. OOP just adopted it later in the wake of nightmare inheritance hierarchies.

Not him/her but I'm writing a compiler, I use functional, sure, but most of it is AST objects, expression objects (which fit OOP very well), internal representations of other objects. Lorra, lorra objects. Working well.

> Popular recent languages like Go, Rust, and Swift borrow a lot from functional programming paradigms.

golang doesn't. It's quite the antithesis really. They embrace mutability, no null safety, and only recently got generics.

This hasn't been my experience. FP is a fantastic complement to OOP for "practical" programming. It adds an entirely new dimension and avenue for expressability which is why we're seeing more and more OOP languages borrow heavily from FP. For all its abstractions, OOP tends to encourage stateful design and accumulate complexity which is where FP shines.

Interesting. Throughout college and the first 4-5 years of my professional career I only knew OO. Then I learned some FP and it made me a much better OO programmer. Specifically, immutable data and pure functions are probably the 2 most important concepts that improve the code that I write in OO-focused languages. I couldn't believe that I was without those techniques for so many years.

This is my own inexperience with OOP showing: I keep wondering if trait/protocol/interface programming has made inheritance entirely worthless. Love Rust. I've been working in Java for other reasons, but I've been noticing more and more Rust-like things in Java over the past year.

What a particular experience.

Nowadays I can find a few isolated uses for "classes", but never, and I mean not a single situation where "OOP" (object ORIENTED programming) could ever be preferrable to just using data and functions, whether that's strictly functional programming or plain old procedural.

Could you share more about where you believe OOP hierarchies offer an advantage?

Games

ECS is I believe most popular game architecture to achieve high performance and code maintainability, displacing OOP in most non-Godot games. And for Godot in particular, there's Godex which provides ECS for it and candidly beats default Godot OOP idioms by using a more functional approach.

Writing UIs is a big one imo

How do you explain the industry-wide switch away from OOP frameworks to things like React and other Elm-architecture derived libraries?

I personally have used a lot of UI libraries, and I would never willingly use anything object oriented again even before React clearly became "the thing". So this is a fairly suprising claim to me in 2022, not so much if it had occurred 10 years ago.

There are many different programming paradigms; Logic, functional, declarative, iterative, OOP, stack-based (if you consider Forth style languages their own paradigm). Each has its pros and cons.

>> much more widely used and honestly now in hindsight probably better tool in most cases.

Knowing only OOP means OOP becomes the only tool for all cases.

Reply on news.ycombinator.com