3 ms·

I've heaard a lot about functional programming but I still not getting how it should be superior to object oriented? I feel OO brings to the table concerete bes

I've heaard a lot about functional programming but I still not getting how it should be superior to object oriented? I feel OO brings to the table concerete best pratices (everything should be an object, object have state, class defines object bejavior, class inheritance, objects encapsulation...) that's broken by functional.

escherize 11y ago
Hi! I have been a programmer for a couple years and started picking up clojure after watching a few of rich hickeys talks. This is the one that best satisfies your question, imho: http://youtu.be/-6BsiVyC1kM http://youtu.be/-6BsiVyC1kM
s73v3r 11y ago
One of the bigger sources of bugs in OO programming is state changing unexpectedly. Functional programming seeks to minimize that.
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.
sklogic 11y ago
These are two orthogonal concepts. FP is analysable, and it is its main (if not the only) point. OOP is a model of a world (and, I'd say, it's a pretty crappy model, but it has nothing to do with languages and such, it's the problem with modelling approach). They have nothing in common.

escherize 11y ago

Hi! I have been a programmer for a couple years and started picking up clojure after watching a few of rich hickeys talks. This is the one that best satisfies your question, imho: http://youtu.be/-6BsiVyC1kM http://youtu.be/-6BsiVyC1kM

s73v3r 11y ago

One of the bigger sources of bugs in OO programming is state changing unexpectedly. Functional programming seeks to minimize that.

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.

sklogic 11y ago

These are two orthogonal concepts. FP is analysable, and it is its main (if not the only) point. OOP is a model of a world (and, I'd say, it's a pretty crappy model, but it has nothing to do with languages and such, it's the problem with modelling approach). They have nothing in common.