11 ms·

FP is the best thing since sliced bread, don't get me wrong! But the seemingly arising "Haskell religion" is at least as mislead as the OOP-religion that held

FP is the best thing since sliced bread, don't get me wrong! But the seemingly arising "Haskell religion" is at least as mislead as the OOP-religion that held mainstream in stranglehold for a long time. Haskell's syntax isn't anything to imitate. It's hostile to IDE features, at least. Alone that should make it a no-go. The next thing is that Haskell's features may make sense in the Haskell context, but they don't make any sense at all in almost any other language. When you don't have strong types, no lazy evaluation by default, and it's not mandatory to use IO-wrappers, it makes not sense to mimic solutions that arose out necessities that are again results of constrains of Haskell's feature design. You need to do some things in Haskell the Haskell way because Haskell is the way it is. In a different language the chosen solutions are at best bonkers (even they may make sense for Haskell). As always: It's a terrible idea to start doing something because "it's cool" and the "new hot shit", without actually understanding why exactly things are (or should be) done the way they are. The "Haskell religion" is by now imho already mostly only cargo cult… The more worrisome part is that it seems it attracts more and more acolytes. This will end up badly. It will likely kill the good ideas behind FP and only leave a hull of religious customs that the cult followers will insist on; exactly like it happened to OOP in the past. That's my personal opinion, speaking as a big FP Scala fan.

misja111 4y ago
> But the seemingly arising "Haskell religion" is at least as mislead as the OOP-religion that held mainstream in stranglehold for a long time. I wanted to say the same but you were faster than me. The article reminded me a lot of the design patterns fad in the OOP world: that compulsion to make everything abstract and reusable even if there's no use for it yet. But hey, at some point it might be needed and then it would be great! Of course there are some cases where you really want to be ahead of what might come , e.g. public library api's, but those are rare.
- celeritascelery 4y ago
  I have heard is said that both OOP and functional design are best applied only about 80% of the time. More than that and you are overfitting the method to things where it applies poorly.
  - pencilguin 4y ago
    Every big enough system has a few parts that would fit OOP, and a few parts that would fit FP. If your language supports those, then great, use those for them. The overwhelming majority of problems do not fit OO, and using OOP on them makes a mess. Similarly, FP.
deltasevennine 4y ago
This opinion is also biased. We have no theoretical method for determining which design philosophy is better than the other. We can't know whether the OOP religion is better, we also can't know if the Haskell religion is better, and we can't know whether NEITHER is better. (this is key, even the neutral point of view where both are "good" can't be proven). We do have theories to determine algorithmic efficiency. Computational complexity allows us to quantify which algorithm is faster and better. But whether that algorithm was better implemented using FP concepts or OOP concepts, we don't know... we can't know. A lot of people like you just pick a random religion. It may seem more reasonable and measured to pick the neutral ground. But this in itself is A Religion. It's the "it's all apples and oranges approach" or the "FP and OOP are just different tools in a toolbox" approach.... but without any mathematical theory to quantify "better" there's no way we can really ever know. Rotten apples and rotten oranges ALSO exist in a world full of apples and oranges. You can't see it but even on an intuitive level this "opinion" is really really biased. It seems reasonable when you have two options to choose from "OOP" and "FP", but what if you have more options? We have Declarative programming, Lisp style programming, assembly language programming, logic programming, reg-exp... Are we really to apply this philosophy to ALL possible styles of programming? Is every single thing in the universe truly apples and oranges or just a tool in a toolbox? With this many options it's unlikely. Something must be bad, something must be good and many things are better then other things. I am of the opinion that normal Procedural and imperative programming with functions is Superior to OOP for the majority of applications. I am not saying FP is better than imperative programming, I am saying OOP is a overall a bad tool even compared with normal programming. But I can't prove my opinion to be right, and you can't prove it to be wrong. Without proof, all we can do is move in circles and argue endlessly. But, psychologically, people tend to fall for your argument because it's less extreme, it seemingly takes the "reasonable" mediator approach. But like I said even this approach is one form of an extreme and it is not reasonable at all. I mean your evidence is just a bunch of qualitative factoids. An opponent to your opinion will come at you with another list of qualitative factoids. You mix all the factoids together and you have a bigger list of factoids with no definitive conclusion.
- still_grokking 4y ago
  Nobody argued for any "better". The point is: When things become a religion with cargo culting acolytes even the "best" approaches stop making sense. That's completely independent of the concrete religion at hand. I did not argue to "pick sides"! In the end all the approaches are just tools. You need to wield them wisely for optimal results.
tikhonj 4y ago
JavaScript et al do have IO wrappers, they just call them promises and only force some effects through them.
- still_grokking 4y ago
  The key word here was "mandatory usage". BTW: Haskell uses its IO wrapper also only for a very narrow set of effects. One of my favorite examples: `head []` will result in a crash at runtime. IO won't safe you. (Besides that the whole "effect wrapping" story in Haskell is anyway shallow at best. There is nothing like "none observable effects" at all as every computation needs to happen in space-time, leaving observable traces therein; you can't define away "side channels" and call the result "pure"; that's mocking reality).
  - cies 4y ago
    > One of my favorite examples: `head []` This is realllly unidiomatic in real world Haskell. Even removed from Elm and PureScript. Idris maybe has better effect handling for your taste. Also see: Koka, Frank (mainly a paper)
    - gottlobflegel 4y ago
      > This is realllly unidiomatic in real world Haskell. Yet it is the actual behaviour in the stdlib Prelude.
      - 1-more 4y ago
        Yep. I think it is needed to satisfy some category theory thing but I never got a good answer on that. I like to use nri-prelude since I went from Elm to Haskell and it has the same idioms, to wit `head : List a -> Maybe a`.
      - cies 4y ago
        Yes. Because it's hard to remove things from the stdlib. More languages suffer from that. What's nice is that the Haskell community offers several alternative Preludes; mostly fixing the problem you describe. Hence I find the example a bit disingenuous.
chongli 4y ago
Haskell's syntax isn't anything to imitate. It's hostile to IDE features, at least. Can you elaborate on this? I haven't used Haskell in years but I recall enjoying some of its really cool IDE-friendly features, such as typed holes and the ability to press a key and have whatever is under my editor's cursor show me its type and another key to insert that inferred type into the document. I have heard that more recent versions support nice record syntax using the '.' operator (but without whitespace, to differentiate it from composition). That's also very IDE friendly since type inference in the editor should be able to resolve the members of a data type that's been defined with record syntax.
- still_grokking 4y ago
  The main problem is discovery. When I hold some object I can easily discover the things I can do with that object—just by typing "." after the object reference. In something like Haskell I need to know upfront what I may do with some "object". The IDE can't help me discover the methods I need. All it can do is to show me all available functions in scope. Most of this functions aren't what I'm looking for. But the IDE can't know that as it's missing the "context" in which I want to call my functions / methods. And regarding records in Haskell: First of all you will get beaten when you use them (that's part of the religious movement and has nothing to do with comprehensible reasons). The other part is: Records are no substitute for objects. Not even close. Those are just quite primitive structs. (To learn how unpractical is it to try to build objects from structs without proper language support just ask someone who was forced to use C after coming from a more complete OO language).
  - TremendousJudge 4y ago
    to quote grugbrain.dev: >grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug >big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct >grug say tool magic pop up of what can do and complete of code major most benefit of type system, correctness also good but not so nearly so much
ladyattis 4y ago
I'm biased but I find the pattern for FP in LISP-like languages easier to understand. I think that and other languages with FP facilities are better to emulate than Haskell which seems more focused on mathematicians.
efnx 4y ago
I think a lot of this (to quote the Dude) “is just like, your opinion, man”. Haskell is great but it’s not for everybody. It really gets you thinking about software engineering in a different way. I wrote Haskell full time for five years, with some of the best in the industry and I can tell you that there is no real religion. I will admit the language attracts ideologists, theorists and folks who like to pioneer (which I like), but everybody is just trying to make things work - these are patterns that solve problems and guidelines that avoid problems. Now, it’s really hard to take the good parts of Haskell and bring them to a language like JavaScript and have it feel “natural” - especially to someone who isn’t a native Haskell writer! And especially a concept as reliant on higher kinded types as effects!

misja111 4y ago

> But the seemingly arising "Haskell religion" is at least as mislead as the OOP-religion that held mainstream in stranglehold for a long time. I wanted to say the same but you were faster than me. The article reminded me a lot of the design patterns fad in the OOP world: that compulsion to make everything abstract and reusable even if there's no use for it yet. But hey, at some point it might be needed and then it would be great! Of course there are some cases where you really want to be ahead of what might come , e.g. public library api's, but those are rare.

celeritascelery 4y ago
I have heard is said that both OOP and functional design are best applied only about 80% of the time. More than that and you are overfitting the method to things where it applies poorly.
- pencilguin 4y ago
  Every big enough system has a few parts that would fit OOP, and a few parts that would fit FP. If your language supports those, then great, use those for them. The overwhelming majority of problems do not fit OO, and using OOP on them makes a mess. Similarly, FP.

deltasevennine 4y ago

This opinion is also biased. We have no theoretical method for determining which design philosophy is better than the other. We can't know whether the OOP religion is better, we also can't know if the Haskell religion is better, and we can't know whether NEITHER is better. (this is key, even the neutral point of view where both are "good" can't be proven). We do have theories to determine algorithmic efficiency. Computational complexity allows us to quantify which algorithm is faster and better. But whether that algorithm was better implemented using FP concepts or OOP concepts, we don't know... we can't know. A lot of people like you just pick a random religion. It may seem more reasonable and measured to pick the neutral ground. But this in itself is A Religion. It's the "it's all apples and oranges approach" or the "FP and OOP are just different tools in a toolbox" approach.... but without any mathematical theory to quantify "better" there's no way we can really ever know. Rotten apples and rotten oranges ALSO exist in a world full of apples and oranges. You can't see it but even on an intuitive level this "opinion" is really really biased. It seems reasonable when you have two options to choose from "OOP" and "FP", but what if you have more options? We have Declarative programming, Lisp style programming, assembly language programming, logic programming, reg-exp... Are we really to apply this philosophy to ALL possible styles of programming? Is every single thing in the universe truly apples and oranges or just a tool in a toolbox? With this many options it's unlikely. Something must be bad, something must be good and many things are better then other things. I am of the opinion that normal Procedural and imperative programming with functions is Superior to OOP for the majority of applications. I am not saying FP is better than imperative programming, I am saying OOP is a overall a bad tool even compared with normal programming. But I can't prove my opinion to be right, and you can't prove it to be wrong. Without proof, all we can do is move in circles and argue endlessly. But, psychologically, people tend to fall for your argument because it's less extreme, it seemingly takes the "reasonable" mediator approach. But like I said even this approach is one form of an extreme and it is not reasonable at all. I mean your evidence is just a bunch of qualitative factoids. An opponent to your opinion will come at you with another list of qualitative factoids. You mix all the factoids together and you have a bigger list of factoids with no definitive conclusion.

still_grokking 4y ago
Nobody argued for any "better". The point is: When things become a religion with cargo culting acolytes even the "best" approaches stop making sense. That's completely independent of the concrete religion at hand. I did not argue to "pick sides"! In the end all the approaches are just tools. You need to wield them wisely for optimal results.

tikhonj 4y ago

JavaScript et al do have IO wrappers, they just call them promises and only force some effects through them.

still_grokking 4y ago
The key word here was "mandatory usage". BTW: Haskell uses its IO wrapper also only for a very narrow set of effects. One of my favorite examples: `head []` will result in a crash at runtime. IO won't safe you. (Besides that the whole "effect wrapping" story in Haskell is anyway shallow at best. There is nothing like "none observable effects" at all as every computation needs to happen in space-time, leaving observable traces therein; you can't define away "side channels" and call the result "pure"; that's mocking reality).
- cies 4y ago
  > One of my favorite examples: `head []` This is realllly unidiomatic in real world Haskell. Even removed from Elm and PureScript. Idris maybe has better effect handling for your taste. Also see: Koka, Frank (mainly a paper)
  - gottlobflegel 4y ago
    > This is realllly unidiomatic in real world Haskell. Yet it is the actual behaviour in the stdlib Prelude.
    - 1-more 4y ago
      Yep. I think it is needed to satisfy some category theory thing but I never got a good answer on that. I like to use nri-prelude since I went from Elm to Haskell and it has the same idioms, to wit `head : List a -> Maybe a`.
    - cies 4y ago
      Yes. Because it's hard to remove things from the stdlib. More languages suffer from that. What's nice is that the Haskell community offers several alternative Preludes; mostly fixing the problem you describe. Hence I find the example a bit disingenuous.

chongli 4y ago

Haskell's syntax isn't anything to imitate. It's hostile to IDE features, at least. Can you elaborate on this? I haven't used Haskell in years but I recall enjoying some of its really cool IDE-friendly features, such as typed holes and the ability to press a key and have whatever is under my editor's cursor show me its type and another key to insert that inferred type into the document. I have heard that more recent versions support nice record syntax using the '.' operator (but without whitespace, to differentiate it from composition). That's also very IDE friendly since type inference in the editor should be able to resolve the members of a data type that's been defined with record syntax.

still_grokking 4y ago
The main problem is discovery. When I hold some object I can easily discover the things I can do with that object—just by typing "." after the object reference. In something like Haskell I need to know upfront what I may do with some "object". The IDE can't help me discover the methods I need. All it can do is to show me all available functions in scope. Most of this functions aren't what I'm looking for. But the IDE can't know that as it's missing the "context" in which I want to call my functions / methods. And regarding records in Haskell: First of all you will get beaten when you use them (that's part of the religious movement and has nothing to do with comprehensible reasons). The other part is: Records are no substitute for objects. Not even close. Those are just quite primitive structs. (To learn how unpractical is it to try to build objects from structs without proper language support just ask someone who was forced to use C after coming from a more complete OO language).
- TremendousJudge 4y ago
  to quote grugbrain.dev: >grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug >big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct >grug say tool magic pop up of what can do and complete of code major most benefit of type system, correctness also good but not so nearly so much

ladyattis 4y ago

I'm biased but I find the pattern for FP in LISP-like languages easier to understand. I think that and other languages with FP facilities are better to emulate than Haskell which seems more focused on mathematicians.

efnx 4y ago

I think a lot of this (to quote the Dude) “is just like, your opinion, man”. Haskell is great but it’s not for everybody. It really gets you thinking about software engineering in a different way. I wrote Haskell full time for five years, with some of the best in the industry and I can tell you that there is no real religion. I will admit the language attracts ideologists, theorists and folks who like to pioneer (which I like), but everybody is just trying to make things work - these are patterns that solve problems and guidelines that avoid problems. Now, it’s really hard to take the good parts of Haskell and bring them to a language like JavaScript and have it feel “natural” - especially to someone who isn’t a native Haskell writer! And especially a concept as reliant on higher kinded types as effects!