Consequently, whenever someone feels they understand Monads they are compelled to write a tutorial to demonstrate their understanding and consequent elevation to "true programmer" status. There is a large audience for these tutorials as all the "non-true" programmers struggle to reach this stage.
I certainly only wanted to understand Monads because they sounded cool, not really because I wanted to become a better programmer. Although I certainly found this to be quite a positive side-effect in my struggles to become a "true" programmer.
That definitely doesn't make it "not simple" - it's the simplicity that's the trouble :-P
They solve a major problem that Haskell has (namely circumventing a type-anal non-strict compiler), so they're a big deal in Haskell, whereas in imperative languages straightforward code works just fine.
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 (nor is it as syntactically localized as a for loop) so it's not as easy to abstract. I.e. the underlying pattern is not as pronounced, so it's not really recognized as a pattern/problem/something to DRY in the first place.
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.
Monads don't circumvent anything.
"in imperative languages straightforward code works just fine"
Or seems to, but is actually deeply broken. Which is regularly the case in the code bases I deal with day-to-day.
"the use case for this kind of function chaining doesn't appear all that often"
Or it does, and you miss it. All of computation can be expressed as function chaining. Writing C or Python, I've often wanted to be able to constrain things at that level.
That's my point. Aside from my lack of amusement by Haskell's type system, I'm not making any moral or qualitative judgements one way or another. I'm talking about programmers in general. The parent's question was why monads are difficult to convey. My argument is that, in the first place, the pattern monads are DRYing is not obvious to people, and might not even be recognized as a pattern in the first place.
They don't teach you number theory before arithmetic in primary school. Similarly, you don't need to understand monads before you use IO.