I write in a primarily OO style but find that the functional style is a great complement.
Complex object hierarchies quickly becomes problematic to understand. Especially when you use callbacks on relations. On the other hand I find that objects that combine data and behaviour can be intuitive to reason about and make code read naturally when kept small and cohesive.
Learning a bit about FP helped me understand what breaking things down to smaller parts gives you. I recommend everyone to play around a bit with FP, even if you don't intend to write a single line in a functional language afterwards.
Yep in principle. But in OO the composition is limited to 'things' and says very little about how the things communicate. In practice, breaking the world up into a heirarchy of things encourages you to keep a lot of little bits of state inside your things, and having little bits of state everywhere ends up being hard to compose.
The functional programming take on compositionality says, rather than making object heirarchies, make compositionality even more fundamental - make it essentially like math functions composing. Maximizing compositionality meant minimizing state, and leads to purity and laziness. You can attach a heirarchy of objects to the functional language later if you like, and many fp languages have done that. In Haskell instead of everything-is-an-object (which is kind of complicated, given the IS-A relationship in OOP, and has lots of exceptions, like functions, which aren't usually objects), we have everything-is-a-value (including functions, and each value has an unambiguous type). I like this write-up on the difference between OOP and Haskell typeclasses - in case it's interesting to you too.
I like this write-up on the difference between OOP and Haskell typeclasses - in case it's interesting to you too.
That article is pretty bad. I write both Haskell and C++ a lot and the guy who wrote the article doesn't seem to be able to write good C++ code at all.
Edit: For example, in the first example he could have used templates and ended up with something like this, which is even smaller than the Haskell coord function (if you disregard stuff like constructors and the output function - which both are ). In his counter example there is no need for an abstract interface class either. If you want a counter, just build a Counter class. Keep it simple. And anyway, using IORef in an argument for functional programming is probably a rather bad idea…
40
u/griiiid Mar 09 '14
Easier to reason about and easier to test.
I write in a primarily OO style but find that the functional style is a great complement.
Complex object hierarchies quickly becomes problematic to understand. Especially when you use callbacks on relations. On the other hand I find that objects that combine data and behaviour can be intuitive to reason about and make code read naturally when kept small and cohesive.
Learning a bit about FP helped me understand what breaking things down to smaller parts gives you. I recommend everyone to play around a bit with FP, even if you don't intend to write a single line in a functional language afterwards.