4 ms·
As someone who has been through C -> C++ -> C# and now F# and Haskell, I understand why initially you wouldn't see what needs fixing. The problem I have found
by louthy 11y ago
As someone who has been through C -> C++ -> C# and now F# and Haskell, I understand why initially you wouldn't see what needs fixing. The problem I have found as I have been working with larger and larger OO programs is that they're incredibly difficult to manage in my mind. Mutable state, dependency hierarchies, hidden state, unknown side-effects, etc. Moving to functional programming has made everything much simpler (for me).
The idea of an object is fine, but it doesn't need methods attached to it. Also, by making an object immutable, anything can have a reference to it, and do what it likes with it because everything else pointing to it essentially has a 'snapshot' of the world at that point-in-time.
That makes it very easy to move packets of data around a system, without the burden of the attached methods. And if multiple processes have a reference to the object, they know that what they know is true now, is going to be true when they come back to use the object again.
Once you detach the functionality from the data, and once the thing you're pointing at can't change, then you realise that actually everything you do (applying functions) is a projection from an input to an output, and that state is an emergent property of the function. Therefore you don't need to manage this morass of ever changing objects.
A request can project to a response, a query can project to a list of results, etc.
Then all outputs are dependent on only one thing, the input. Not shared mutable state, not unknown side-effects, etc. Then everything is testable and provable, and it's very easy to test and prove, rather than requiring elaborate mocking frameworks, dependency injection, etc.
The more I did this, the easier I found it to keep a mental map of my programs. And ultimately that's the major thing that programmers have to deal with. It's our own weak and feeble minds that get in the way of developing more complex programs, and we've developed these elaborate techniques to help ourselves.
For me functional programming is another one of those crutches, and it's a damn powerful one. Because I know that once a function, that projects an immutable type to another immutable type is written, it stays written. It doesn't suffer from code-rot as the rest of the app grows around it. I can then safely park that part of the program in the 'done' pile and never worry about it again.
Finally, most of the things that are supposed to be OOP's strong points (like polymorphism, encapsulation and modularity), I feel, can be done better in functional languages. Pretty much every pattern in the GoF Design Patterns book can be better implemented using functional techniques.
Anyway, your mileage may vary obviously, but as a reformed OO programmer, I'd definitely advise you to give it a shot. It takes a bit of time to sink in, but it's worth it.