Comment by munchbunny | Hacker News Reader

Comment by munchbunny | Hacker News Reader

Parent Full thread

To be fair, a lot of OO code tends toward overengineering and premature abstraction.

And a lot of functional code tends towards unnecessary levels of indirection through higher order functions as a way of deferring responsibility for actual logic, or on the flipside insufficient abstraction leading to difficulty extending functionality.

I've gone back and forth multiple times between functional practices and OO practices, and I definitely empathize with the confusion going in both directions. You trade one problem for another, and in the end there really is no free lunch.

React Redux is a great example. People who have gotten over the hump of the boilerplate involved in threading state up and down the tree love how little energy they're spending routing state changes to the correct destinations. However, to someone who is used to event-based UI programming, this looks like a horrific waste of energy reminiscent of how a giraffe's laryngeal nerve goes all the way down the neck then back up. They've both got a point, but you have to follow their paths to see it yourself.

"I've gone back and forth multiple times between functional practices and OO practices, and I definitely empathize with the confusion going in both directions. You trade one problem for another, and in the end there really is no free lunch."

I think there is a strange kind of duality between OOP and FP. I think OOP passes structures of objects hidden behind interfaces, while the FP passes composed functions in other direction. So you can convert your OOP code to FP code almost mindlessly by total "inversion of control" - wherever you pass an object somewhere (making a call), in FP you pass the operation from the callee to the caller instead.

And I think it's this duality that you observe in practice.

However, I believe there is a practical difference between the two, which makes FP superior despite being harder to understand initially.

It's much easier to spot that you're doing "no-ops" in FP than in OOP. In OOP, often you pass the objects unchanged across layers, while in FP, this manifests as identity functions being used. And it's easier for both human and compiler to remove these redundant identity functions (through function specialization and things like fusion etc.).

Also, I believe functional approach allows you to better realize that there are some algebraic laws governing your problem domain.

It's really kind of like in mathematics, when you come from point-wise understanding of functions to functional understanding of functions, more insight is gained.

Reply on news.ycombinator.com