Please, let's put aside the denotational debate, because I'm frankly not interested in it, and it is pointless.
That may be, but you have convinced me! I should be stating pure FP specifically, to avoid confusion :-)
When you said "Haskell is bad for FP", what are the concepts you were referring too? And in what way was Haskell bad for them?
I was referring specifically to (primarily statically typed and compiled) purely functional programming. I don't think Haskell has too much influence over impure languages.
If I had to summarize my issues, I would say that Haskell, for a flagship language, strays too far from the core concepts of purely functional programming / typed lambda calculus. It adds complexity (String/Text, typeclasses, lazyness...), reduces certain arguably desirable properties (errors break programs-as-proofs) and it is inflexible in how it represents the imperative world in a functional context, pushing IMO too much coding in IO monads, which is essentially imperative programming.
Because Haskell is, again, the flagship of pure fp, it really shapes the notion of what pure (typed) fp is. I think this may be bad for adoption and innovation.
At this point, though, I should probably write a new post about what I think purely functional programming could / should be.
Haha, ya, I think if you added pure in front of FP for your post title, all confusion would have been avoided, at least for me.
Especially because I think purity is a hurdle for newcomers, and a hard stepping stone. So I find if people start with impure, and gradually of their own learn the benefits of purity and the mechanism to write more and more pure code, it can be a better stepping stone for them moving to a purely FP language like Haskell. It's a more gradual learning curve, I feel.
So I actually thought that this was what you meant also.
I'd actually be really interested in that follow up post you mention. Because my only experience with purely functional languages is Haskell. And I was under the impression that most of the concepts you say bring too much complexity were actually necessary to upheld purity.
For example, without typeclasses, I thought the type system would be a lot weaker, and you'd lose quit a bit of its expressiveness. That without laziness and non-strict evaluation, you were not able to isolate side effects and extract them out of your functions so they evaluate purely. I also thought you couldn't match the performance of impure algorithms without it. And similarly, without Monads and its syntax sugar over them, IO effects couldn't be tracked and controlled by the type system.
Basically, I've always been under the impression that all of Haskell's complexity was due to it trying to maintain purity at all cost.
So I'm intrigued to learn of alternative ways, that could be arguably simpler, yet would still allow for practical, performant and strictly pure code.
Please, let's put aside the denotational debate, because I'm frankly not interested in it, and it is pointless.
Let's discuss the concepts and intended meanings instead. And so let me ask you a question:
When you said "Haskell is bad for FP", what are the concepts you were referring too? And in what way was Haskell bad for them?
That may be, but you have convinced me! I should be stating pure FP specifically, to avoid confusion :-)
I was referring specifically to (primarily statically typed and compiled) purely functional programming. I don't think Haskell has too much influence over impure languages.
If I had to summarize my issues, I would say that Haskell, for a flagship language, strays too far from the core concepts of purely functional programming / typed lambda calculus. It adds complexity (
String/Text, typeclasses, lazyness...), reduces certain arguably desirable properties (errors break programs-as-proofs) and it is inflexible in how it represents the imperative world in a functional context, pushing IMO too much coding in IO monads, which is essentially imperative programming.Because Haskell is, again, the flagship of pure fp, it really shapes the notion of what pure (typed) fp is. I think this may be bad for adoption and innovation.
At this point, though, I should probably write a new post about what I think purely functional programming could / should be.
Haha, ya, I think if you added pure in front of FP for your post title, all confusion would have been avoided, at least for me.
Especially because I think purity is a hurdle for newcomers, and a hard stepping stone. So I find if people start with impure, and gradually of their own learn the benefits of purity and the mechanism to write more and more pure code, it can be a better stepping stone for them moving to a purely FP language like Haskell. It's a more gradual learning curve, I feel.
So I actually thought that this was what you meant also.
I'd actually be really interested in that follow up post you mention. Because my only experience with purely functional languages is Haskell. And I was under the impression that most of the concepts you say bring too much complexity were actually necessary to upheld purity.
For example, without typeclasses, I thought the type system would be a lot weaker, and you'd lose quit a bit of its expressiveness. That without laziness and non-strict evaluation, you were not able to isolate side effects and extract them out of your functions so they evaluate purely. I also thought you couldn't match the performance of impure algorithms without it. And similarly, without Monads and its syntax sugar over them, IO effects couldn't be tracked and controlled by the type system.
Basically, I've always been under the impression that all of Haskell's complexity was due to it trying to maintain purity at all cost.
So I'm intrigued to learn of alternative ways, that could be arguably simpler, yet would still allow for practical, performant and strictly pure code.
Regards!
Haha, I guess that is a point in favor of the idea that Haskell is too dominant. :-)