9 ms·

I don't find this article well thought out. One, the writer presents OOP and FP as opposing paradigma's. While object oriented programming is orthogonal to func

I don't find this article well thought out. One, the writer presents OOP and FP as opposing paradigma's. While object oriented programming is orthogonal to functional programming. You can have a purely functional programming language with objects. Two: 100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work Doesn't work for what? I think pure functional programming has its place, it is not just for everything you want to do. But object oriented programming is also not meant for every domain. It is like saying scalpels are stupid, because you can't build a house with them.

ratww 6y ago
> Doesn't work for what? It implies that FP doesn't work in the real world without IO or without a runtime. When the author talks about "the messy parts that interact with the outside world" he's talking about the "Functional Core Imperative Shell" concept [1]. [1] https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct...
- hopia 6y ago
  So then why doesn't "98% pure functional programming" work either as the author puts it?
- pinopinopino 6y ago
  Of course lambda calculus doesn't work in the real world, the canonical purely functional language. It doesn't work, because it are just functions and those need input before they become useful. A function just sitting on paper doesn't compute anything. However that is not entirely true, we can perhaps view analogue computers as purely functional computers, albeit one with continuous functions. But besides such a weird example, we should not kid ourselves, most imperative languages these days also need a runtime. And if you take that a step further, assembly also needs a runtime. But that is I think not a honest argument, but still something to think about. If we pursue this further down then we arrive at physical phenomena that do the computations. Are those imperative or functional? But now we are just playing around.
jayd16 6y ago
The objects would be fully public structs only though, yes? >Doesn't work for what? Doesn't work for performance, too much copying of immutable state. If 100% pure means zero mutation, you can't even fit the definition of a program and write output /s
- dnautics 6y ago
  I think people care about performance without thinking about what exactly the bottleneck is. In some cases, it's the thing in front of the keyboard, in which case, you can do plenty of immutable state copying without worrying about it.
  - MaulingMonkey 6y ago
    > I think people care about performance without thinking about what exactly the bottleneck is Some of us are just permanently immersed in performance critical stuff. In gamedev, a single millisecond is a significant chunk of my per-frame budget and can stick out like a sore thumb in my profiling flamegraphs as an optimization opportunity / potential cause for hitching. Pure functional code still has plenty of uses in this environment, but we've also got large chunks of our codebases dedicated to mutating external state (GPUs, Network IO, etc.) in horrifically performance sensitive ways.
    - dnautics 6y ago
      > In gamedev, a single millisecond is a significant chunk of my per-frame budget and can stick out like a sore thumb in my profiling flamegraphs as an optimization opportunity / potential cause for hitching Yes, but what is the relative portion of gamedevs among all devs? These people know who they are and they should absolutely obsess over performance. Everyone else should stop and think first. Okay, okay. I'll make another carveout for certain classes of HPC. But even here, as the joke goes, HPC is the art of taking a CPU-bound task and turning it into an IO-bound task. I have heard of HPC people optimizing their numpy application to really run like the dickens on an HPC cluster, the scale their deploy from 1 to 40,000 nodes, and have the filesystem lock up for hours on what should be a 15 minute task due to the way python takes out r/w transactional locks on each and every one of its import statements.
dnautics 6y ago
You can basically get the type of structured programming author is looking for with fully public structs in a functional language. And the pureness of functional paradigm is a bit of a strawman. Coming off of mostly C, C++, ruby, and python, I exclusively program in functional languages and have been for almost a decade now (wow!), and none of the fp langs (julia, elixir, erlang, react) that I have used have been "purely" functional. They all expose state (using different techniques - (bang functions, actors, actors, hooks) which are extremely well calibrated to the needs of their practioners. While that leads to a bit of fragmentation, it does also mean that the quality of code you release is better, because you're protected from making common mistakes that in my pre-FP experience, led to much teeth gnashing and hair pulling.
dev_tty01 6y ago
>Doesn't work for what? >I think pure functional programming has its place, it is not just for everything you want to do. But object oriented programming is also not meant for every domain. It is like saying scalpels are stupid, because you can't build a house with them. You answered your own question. "It is not just for everything you want to do." He didn't say it was stupid. He said is is not for everything you want to do. You and the author are in agreement.
peter_retief 6y ago
The article is clear to me. Dont chase a dogma rather let the data define how you code.
specialp 6y ago
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.
tgflynn 6y ago
> You can have a purely functional programming language with objects. Yes, but those objects would have to be immutable. Much (probably most) OOP and procedural software works with mutable data structures, which are forbidden by pure FP.

ratww 6y ago

> Doesn't work for what? It implies that FP doesn't work in the real world without IO or without a runtime. When the author talks about "the messy parts that interact with the outside world" he's talking about the "Functional Core Imperative Shell" concept [1]. [1] https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct...

hopia 6y ago
So then why doesn't "98% pure functional programming" work either as the author puts it?
pinopinopino 6y ago
Of course lambda calculus doesn't work in the real world, the canonical purely functional language. It doesn't work, because it are just functions and those need input before they become useful. A function just sitting on paper doesn't compute anything. However that is not entirely true, we can perhaps view analogue computers as purely functional computers, albeit one with continuous functions. But besides such a weird example, we should not kid ourselves, most imperative languages these days also need a runtime. And if you take that a step further, assembly also needs a runtime. But that is I think not a honest argument, but still something to think about. If we pursue this further down then we arrive at physical phenomena that do the computations. Are those imperative or functional? But now we are just playing around.

jayd16 6y ago

The objects would be fully public structs only though, yes? >Doesn't work for what? Doesn't work for performance, too much copying of immutable state. If 100% pure means zero mutation, you can't even fit the definition of a program and write output /s

dnautics 6y ago
I think people care about performance without thinking about what exactly the bottleneck is. In some cases, it's the thing in front of the keyboard, in which case, you can do plenty of immutable state copying without worrying about it.
- MaulingMonkey 6y ago
  > I think people care about performance without thinking about what exactly the bottleneck is Some of us are just permanently immersed in performance critical stuff. In gamedev, a single millisecond is a significant chunk of my per-frame budget and can stick out like a sore thumb in my profiling flamegraphs as an optimization opportunity / potential cause for hitching. Pure functional code still has plenty of uses in this environment, but we've also got large chunks of our codebases dedicated to mutating external state (GPUs, Network IO, etc.) in horrifically performance sensitive ways.
  - dnautics 6y ago
    > In gamedev, a single millisecond is a significant chunk of my per-frame budget and can stick out like a sore thumb in my profiling flamegraphs as an optimization opportunity / potential cause for hitching Yes, but what is the relative portion of gamedevs among all devs? These people know who they are and they should absolutely obsess over performance. Everyone else should stop and think first. Okay, okay. I'll make another carveout for certain classes of HPC. But even here, as the joke goes, HPC is the art of taking a CPU-bound task and turning it into an IO-bound task. I have heard of HPC people optimizing their numpy application to really run like the dickens on an HPC cluster, the scale their deploy from 1 to 40,000 nodes, and have the filesystem lock up for hours on what should be a 15 minute task due to the way python takes out r/w transactional locks on each and every one of its import statements.

dnautics 6y ago

You can basically get the type of structured programming author is looking for with fully public structs in a functional language. And the pureness of functional paradigm is a bit of a strawman. Coming off of mostly C, C++, ruby, and python, I exclusively program in functional languages and have been for almost a decade now (wow!), and none of the fp langs (julia, elixir, erlang, react) that I have used have been "purely" functional. They all expose state (using different techniques - (bang functions, actors, actors, hooks) which are extremely well calibrated to the needs of their practioners. While that leads to a bit of fragmentation, it does also mean that the quality of code you release is better, because you're protected from making common mistakes that in my pre-FP experience, led to much teeth gnashing and hair pulling.

dev_tty01 6y ago

>Doesn't work for what? >I think pure functional programming has its place, it is not just for everything you want to do. But object oriented programming is also not meant for every domain. It is like saying scalpels are stupid, because you can't build a house with them. You answered your own question. "It is not just for everything you want to do." He didn't say it was stupid. He said is is not for everything you want to do. You and the author are in agreement.

peter_retief 6y ago

The article is clear to me. Dont chase a dogma rather let the data define how you code.

specialp 6y ago

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.

tgflynn 6y ago

> You can have a purely functional programming language with objects. Yes, but those objects would have to be immutable. Much (probably most) OOP and procedural software works with mutable data structures, which are forbidden by pure FP.