4 ms·

I write Haskell commercially, and none of the problems you list are problems my team actually has in reality.

adambyrtek 7y ago
Your comment would be much more interesting and constructive if you actually took the time to refute the individual points instead of just saying that it's not a problem for you.
- thedataangel 7y ago
  Sure: 1) Should basically never happen anyway. It's a point of pride on my team that we rarely (as in, maybe once a year) have breakages in production that are actually caused by Haskell - they are almost always caused by something else. On the off chance this very unlikely scenario actually happens, I've never found a Haskell codebase I'm familiar with to be any less readable than ones in other languages. If anything, the reverse is true. The important thing is familiarity, not the language it's written in. 2) Haskell is a language in which research is done. It's also perfectly suitable for production software. The two aren't mutually exclusive. It _does_ have many ways to combine things, but in generally that's seen as a positive. Most of the ways are compatible with one another. The big exception is the distinction between monadic and non-monadic code, but libraries where that distinction matters almost always support both. 3) This is a problem with developers, not the language. If you employ idiots who want to masturbate over academic points for two days instead of doing their jobs, thats your problem. 4) Architecture is much _easier_ to change in Haskell than in other languages, because refactoring is safe and straightforward. Anyone complaining about logging and config has clearly not written enough Haskell to be aware of the common patterns for handling those smoothly. On the _very_ rare occasion that you just need to jam some print-lines somewhere deep for debugging, the Debug.Trace module lets you do that with basically no effort.
h91wka 7y ago
How do you deal with #4?
- coldtea 7y ago
  How is #4 even a problem to begin with? If anything, it's the inverse: "isolation of side effects" means the architecture is more flexible and lego-like -- as opposed to a spaghetti mess. And if you need to change interfaces, you are in for one of the smoothest rides, as the compiler will guide you every step of the way to implementing the change wherever it's needed.
  - mantap 7y ago
    > And if you need to change interfaces, you are in for one of the smoothest rides, as the compiler will guide you every step of the way to implementing the change wherever it's needed. This is the same in any statically typed language. Actually the quality of Haskell/GHC's error messages are limited by constraint-based type inference and languages that have flow-based type inference do a better job IMO.
    - the_af 7y ago
      > This is the same in any statically typed language Surely not in any statically typed language. Languages like Java cannot encode the same useful information (or rather, you cannot force them to) as languages like Haskell. Specifically, you cannot make them enforce lack/presence of IO in their types. Most mainstream statically typed languages cannot do that, in fact.
      - mantap 7y ago
        But it's considered good practice in Haskell to keep IO out of the main logic of the program and basically use it as little as possible. Haskell is certainly not an IO-focused language like Go and Rust. The IO monad is almost more of a deterrent than a tool.
        the_af 7y ago
        That's only partially true. Of course a Haskell program needs to do IO to be useful. The IO Monad is also not a deterrent, where did you get that idea? Haskell is very much IO focused, in fact it's been jokingly called "the world's best imperative language"! Even then, in Haskell you can say "this doesn't do IO" which you cannot in most languages! It's also just an example of the expressiveness of the type system, which "most statically typed" cannot enforce or sometimes even express.

Your comment would be much more interesting and constructive if you actually took the time to refute the individual points instead of just saying that it's not a problem for you.

thedataangel 7y ago
Sure: 1) Should basically never happen anyway. It's a point of pride on my team that we rarely (as in, maybe once a year) have breakages in production that are actually caused by Haskell - they are almost always caused by something else. On the off chance this very unlikely scenario actually happens, I've never found a Haskell codebase I'm familiar with to be any less readable than ones in other languages. If anything, the reverse is true. The important thing is familiarity, not the language it's written in. 2) Haskell is a language in which research is done. It's also perfectly suitable for production software. The two aren't mutually exclusive. It _does_ have many ways to combine things, but in generally that's seen as a positive. Most of the ways are compatible with one another. The big exception is the distinction between monadic and non-monadic code, but libraries where that distinction matters almost always support both. 3) This is a problem with developers, not the language. If you employ idiots who want to masturbate over academic points for two days instead of doing their jobs, thats your problem. 4) Architecture is much _easier_ to change in Haskell than in other languages, because refactoring is safe and straightforward. Anyone complaining about logging and config has clearly not written enough Haskell to be aware of the common patterns for handling those smoothly. On the _very_ rare occasion that you just need to jam some print-lines somewhere deep for debugging, the Debug.Trace module lets you do that with basically no effort.

h91wka 7y ago

How do you deal with #4?

coldtea 7y ago
How is #4 even a problem to begin with? If anything, it's the inverse: "isolation of side effects" means the architecture is more flexible and lego-like -- as opposed to a spaghetti mess. And if you need to change interfaces, you are in for one of the smoothest rides, as the compiler will guide you every step of the way to implementing the change wherever it's needed.
- mantap 7y ago
  > And if you need to change interfaces, you are in for one of the smoothest rides, as the compiler will guide you every step of the way to implementing the change wherever it's needed. This is the same in any statically typed language. Actually the quality of Haskell/GHC's error messages are limited by constraint-based type inference and languages that have flow-based type inference do a better job IMO.
  - the_af 7y ago
    > This is the same in any statically typed language Surely not in any statically typed language. Languages like Java cannot encode the same useful information (or rather, you cannot force them to) as languages like Haskell. Specifically, you cannot make them enforce lack/presence of IO in their types. Most mainstream statically typed languages cannot do that, in fact.
    - mantap 7y ago
      But it's considered good practice in Haskell to keep IO out of the main logic of the program and basically use it as little as possible. Haskell is certainly not an IO-focused language like Go and Rust. The IO monad is almost more of a deterrent than a tool.
      - the_af 7y ago
        That's only partially true. Of course a Haskell program needs to do IO to be useful. The IO Monad is also not a deterrent, where did you get that idea? Haskell is very much IO focused, in fact it's been jokingly called "the world's best imperative language"! Even then, in Haskell you can say "this doesn't do IO" which you cannot in most languages! It's also just an example of the expressiveness of the type system, which "most statically typed" cannot enforce or sometimes even express.