5 ms·

If it were truly a simple concept, it might not need so many tutorials and explanations.

codygman 11y ago
Perhaps they are much simpler than everyone believes they are and the tutorials are the result of people overcomplicating them.
- dack 11y ago
  It still begs the question why monads specifically have this problem, and so many more concepts don't.
  - WillPostForFood 11y ago
    If we can't even understand what "begging the question" means, how can we understand monads? http://begthequestion.info/ http://begthequestion.info/
  - codygman 11y ago
    I'm drawing a blank for now, but I'm almost positive I've came across this phenomenon for many things before.
  - tokipin 11y ago
    I think it's because they solve a problem that people don't realize they have (and truth be told maybe they don't really have it), so the learning process has no motivation. 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.
    - codygman 11y ago
      > 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.
    - dllthomas 11y ago
lmm 11y ago
It's simple but very abstract. The hard part isn't the concept, it's connecting it to anything you're actually familiar with.
- dllthomas 11y ago
  It's hard like abstract algebra is hard. When things are simple, you have fewer tools you can reach for when trying to figure out all the ramifications of your few rules. Simultaneously, when you reach for examples you need to keep straight what properties of your chosen examples are due to them being instances of the abstraction at hand, and which are (from your current perspective) noise. That definitely doesn't make it "not simple" - it's the simplicity that's the trouble :-P
weavie 11y ago
I think Monads have been placed on a pedestal such that many consider that you are not a true programmer until you can understand them. 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.
exDM69 11y ago
The issue here is that too many beginning functional programmers insist on trying to "understand" monads before using them (and get stuck). They don't teach you number theory before arithmetic in primary school. Similarly, you don't need to understand monads before you use IO.
tel 11y ago
Or perhaps just the opposite. The more genuinely simple a concept is the more likely you are to run into it. Since nearly every programming language on the planet can be rightfully said to be built implicitly atop a single monad... it's a very pervasive concept!

Perhaps they are much simpler than everyone believes they are and the tutorials are the result of people overcomplicating them.

dack 11y ago
It still begs the question why monads specifically have this problem, and so many more concepts don't.
- WillPostForFood 11y ago
  If we can't even understand what "begging the question" means, how can we understand monads? http://begthequestion.info/ http://begthequestion.info/
- codygman 11y ago
  I'm drawing a blank for now, but I'm almost positive I've came across this phenomenon for many things before.
- tokipin 11y ago
  I think it's because they solve a problem that people don't realize they have (and truth be told maybe they don't really have it), so the learning process has no motivation. 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.
  - codygman 11y ago
    > 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.
  - dllthomas 11y ago

lmm 11y ago

It's simple but very abstract. The hard part isn't the concept, it's connecting it to anything you're actually familiar with.

dllthomas 11y ago
It's hard like abstract algebra is hard. When things are simple, you have fewer tools you can reach for when trying to figure out all the ramifications of your few rules. Simultaneously, when you reach for examples you need to keep straight what properties of your chosen examples are due to them being instances of the abstraction at hand, and which are (from your current perspective) noise. That definitely doesn't make it "not simple" - it's the simplicity that's the trouble :-P

weavie 11y ago

I think Monads have been placed on a pedestal such that many consider that you are not a true programmer until you can understand them. 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.

exDM69 11y ago

The issue here is that too many beginning functional programmers insist on trying to "understand" monads before using them (and get stuck). They don't teach you number theory before arithmetic in primary school. Similarly, you don't need to understand monads before you use IO.

tel 11y ago

Or perhaps just the opposite. The more genuinely simple a concept is the more likely you are to run into it. Since nearly every programming language on the planet can be rightfully said to be built implicitly atop a single monad... it's a very pervasive concept!