3 ms·

I think it all comes down to one thing: Shared mutable state. We can discuss what is functional and what is OOP, but in general functional programming does not

I think it all comes down to one thing: Shared mutable state. We can discuss what is functional and what is OOP, but in general functional programming does not mutate data in place. OOP does in general with encapsulated instantiated data in classes being operated on in that class. However sometimes it is hard or impossible to avoid shared state even in functional approaches. So I suppose that is the 98% part. Things like databases, connection pools, files. Since I have programmed in Clojure it has made me a better programmer even in OOP languages when I use them. I try to avoid self mutation and shared state as much as possible. I know there is a back and forth on what is the better way to program for a lot of things, but to me avoiding shared state is indisputably better for avoiding surprising bugs, and also for making concurrency much easier.

hagy 6y ago
100% agree that shared mutable state should be minimized regardless of the paradigm used and further agree that it's generally not possible to totally eliminate it. I believe programming in a functional style helps on to adopt a mindset towards minimizing shared mutable state. Also believe functional programming gets one to think in terms of function composition. Even in an OOP-heavy language like Java, one can find themselves developing complex operations as a composition of simpler, reusable operations. While Java may not have proper 1st class function nor solid syntax for working with functional interface, one can still think in terms of composable operations.
pinopinopino 6y ago
>Since I have programmed in Clojure it has made me a better programmer even in OOP languages when I use them That is also my experience when visiting different paradigmas, they make you a better programmer, because they come with a different way of thinking. >However sometimes it is hard or impossible to avoid shared state even in functional approaches. So I suppose that is the 98% part. Things like databases, connection pools, files. True, true, most pure languages have an escape hatch. Or they pretend to you model the IO through some clever mathematical contraptions and then run it in the runtime during, you never guess it, runtime. But I feel that is just playing with words. Computers work with mutable state, so the 100% pure functional language doesn't even exist. > does in general with encapsulated instantiated data in classes being operated on in that class. I agree, but the general case is always a bit dull. There is no reason for a object oriented programming language to not have immutable objects. Every time you call a method that would normally mutate the object, you get a new one. And then perhaps with something like linear types you can make sure, you only used each object once, so you don't spray needless copies all over the place. I think the axis he should be talking about is imperative programming and functional programming, those are opposites.

hagy 6y ago

100% agree that shared mutable state should be minimized regardless of the paradigm used and further agree that it's generally not possible to totally eliminate it. I believe programming in a functional style helps on to adopt a mindset towards minimizing shared mutable state. Also believe functional programming gets one to think in terms of function composition. Even in an OOP-heavy language like Java, one can find themselves developing complex operations as a composition of simpler, reusable operations. While Java may not have proper 1st class function nor solid syntax for working with functional interface, one can still think in terms of composable operations.

pinopinopino 6y ago

>Since I have programmed in Clojure it has made me a better programmer even in OOP languages when I use them That is also my experience when visiting different paradigmas, they make you a better programmer, because they come with a different way of thinking. >However sometimes it is hard or impossible to avoid shared state even in functional approaches. So I suppose that is the 98% part. Things like databases, connection pools, files. True, true, most pure languages have an escape hatch. Or they pretend to you model the IO through some clever mathematical contraptions and then run it in the runtime during, you never guess it, runtime. But I feel that is just playing with words. Computers work with mutable state, so the 100% pure functional language doesn't even exist. > does in general with encapsulated instantiated data in classes being operated on in that class. I agree, but the general case is always a bit dull. There is no reason for a object oriented programming language to not have immutable objects. Every time you call a method that would normally mutate the object, you get a new one. And then perhaps with something like linear types you can make sure, you only used each object once, so you don't spray needless copies all over the place. I think the axis he should be talking about is imperative programming and functional programming, those are opposites.