3 ms·

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

• 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.