,
8 tweets,
2 min read
Read on Twitter
I wish we'd stop debating OOP vs FP, and started debating individual paradigms. Immutability, encapsulation, global state, single assignment, actor model, pure functions, IO in the type system, inheritance, composition... all of these are perfectly possible in either OOP or FP.
Some are better, some are worse, some are highly dependent on context, let's figure that out instead of religuously bashing umbrella terms like OOP and FP. And there may be many more paradigms to discover.
Take encapsulation: in #Haskell, you can choose for a module not to export your type constructors, and only export smart constructors and functions operating on your data structures. Sounds close enough to encapsulation to me.
Or IO: you can use Ports&Adapters pattern and move your IO to the edges of the system. I see no reason why this could not be lifted to the type system, no reason for this to be exclusive to FP languages.
Lambdas: no longer exclusive to FP. PHP has a feature where you can basically turn an object into a lambda using __invoke. You could use this to do things that are reminiscent of Reader Monad or Writer Monad. Not exactly the same but with similar semantics.
My hypothesis is that many proponents of FP are people who have worked exclusively in bad OOP systems and good FP systems, but never in good OOP and bad FP systems.
Inheritance is often the poster child for bad OOP. You can make almost any inheritance better by replacing it with composition. We know that. But we can improve the discussion by talking about heuristics for when and when not to use inheritance, instead of fully dismissing it.
(Here's one heuristic: use inheritance when such inheritance exists in the domain and has a purpose there)
