4 ms·

> They solve a major problem that Haskell has (namely circumventing a type-anal non-strict compiler), so they're a big deal in Haskell, Type anal? lol. Would y

> They solve a major problem that Haskell has (namely circumventing a type-anal non-strict compiler), so they're a big deal in Haskell, Type anal? lol. Would you want a type checker that wasn't anal and exact in what it expects? > whereas in imperative languages straightforward code works just fine. Except when you have to do things concurrently and have to use locks. Mixing pure and impure functions also makes the source of bugs harder to find in my experience. > More to the point, compared to the case of for loops vs `map`, the use case for this kind of function chaining doesn't appear all that often Function chaining appears quite a bit in my Haskell code. > (nor is it as syntactically localized as a for loop) Huh? > the underlying pattern is not as pronounced But, I can tell you that a map will have no side effects and return a specific type whereas I can't guarantee that with a for loop. > so it's not really recognized as a pattern/problem/something to DRY in the first place. You realize that their is also fold and things like mapConcat right? Maybe I'm misunderstanding your argument.

tokipin 11y ago
I'm saying that in imperative languages for loops are more "above the noise" syntactically and frequency-wise than sequential error checking is, at least traditionally. It's not as obvious that there is anything there to give a name to, and so without an underlying motivation, monads are quite a bit more abstract than a lot of other FP concepts.
- dragonwriter 11y ago
  Actually, I think the "underlying motivation" for monads is specifically that they provide a useful abstraction for which there is not an equivalent elsewhere. That does make it harder for those with experience in other programming to form an intuition of the motivation than for abstractions with a close, e.g., imperative counterpart, but it also is why people with experience with monads in environments where they are widely used often look at ways to port them to other environments. Was there a clear, common equivalent, "monads in language foo" would be less popular.

tokipin 11y ago

I'm saying that in imperative languages for loops are more "above the noise" syntactically and frequency-wise than sequential error checking is, at least traditionally. It's not as obvious that there is anything there to give a name to, and so without an underlying motivation, monads are quite a bit more abstract than a lot of other FP concepts.

dragonwriter 11y ago
Actually, I think the "underlying motivation" for monads is specifically that they provide a useful abstraction for which there is not an equivalent elsewhere. That does make it harder for those with experience in other programming to form an intuition of the motivation than for abstractions with a close, e.g., imperative counterpart, but it also is why people with experience with monads in environments where they are widely used often look at ways to port them to other environments. Was there a clear, common equivalent, "monads in language foo" would be less popular.