6 ms·

I'm not sure why the author goes out of his way to avoid saying "monad," but this is certainly a monad analogy blog post whether he wants to call it that or not

I'm not sure why the author goes out of his way to avoid saying "monad," but this is certainly a monad analogy blog post whether he wants to call it that or not. Not that that's necessarily a bad thing; I think this article does a great job of teaching the reader about monads without them knowing it. The subject of the post -- error handling in a purely-functional context -- is usually my go-to example for explaining monads.

bunderbunder 12y ago
> I'm not sure why the author goes out of his way to avoid saying "monad," Explained here: http://fsharpforfunandprofit.com/about/#banned http://fsharpforfunandprofit.com/about/#banned
- slapresta 12y ago
  So they decide to cripple themselves, intentionally restricting their knowledge to avoid being seen as pedantic? I could understand trying to avoid those words for beginners, but it doesn't seem like the site targets beginners only.
  - andor 12y ago
    He explains how and why his code works. Adding too much formal terminology would make it seem like there is another layer of theory you need to grasp before you truly understand what's going on. Complicated terminology is elitist to beginners, because it nullifies first successes in understanding functional programming.
- dons 12y ago
  Because using sloppy language is so much better...
- the_af 12y ago
  I understand why they do it, but I think they're doing themselves a disservice. It's one thing to speak in jargon and wrongly assume your audience will follow you: "So this is obviously a catamorphism. This evidently a job for Kleisli arrows!". And a completely different thing is to construct a solution step by step, using familiar ideas, and then show that it can be seen as a monad, then give a brief explanation of why monads are useful and what motivates them. Which is exactly what the extremely didactic Learn you a Haskell site does (seriously: look at their example for the Writer Monad. It doesn't get more didactic and step-by-step than that) By avoiding the correct technical terms, they are: - Losing precision. - Failing to generalize the concept. - Underestimating their audience's ability to understand new concepts when property explained. The last one in particular kills me. I for one do not assume Visual Basic programmers are incapable or unwilling to learn new things.
  - bunderbunder 12y ago
    If you're familiar with the psychological phenomenon known as priming, that may help help to explain the situation. For someone who's suffered through a few too many many blog posts that explain monads poorly, it is possible that simply mentioning the m-word, even in the very last sentence of the article, may inhibit their ability to comprehend the process. Because of that, there's a certain genius to the article's approach: Give folks who've been struggling with monads and arrows the best possible chance to grasp the concept without being encumbered by all the baggage that has built up around the terminology. If they do get the concept, great, and they're virtually guaranteed to realize shortly afterward, "Oh hey, forehead smack, those are monads!" (Incidentally, for people who've found themselves thrust into this unfortunate situation, a chapter titled A Fistful of Monads probably isn't likely to help much.) To that end, I'd even go so far as to say your worries about that last bullet point underestimate the audience's ability to understand new concepts when properly explained much worse than the author did.
    - steveklabnik 12y ago
      > even in the very last sentence of the article, I am not a psychologist, but isn't part of the definition of priming that it happens before? How would saying something afterwards harm your ability to previously understand something? Well, I guess I could see how that'd be possible, but I'm not sure that's priming anymore.
      - tlarkworthy 12y ago
        I don't read every article top to bottom, I would waste too much time doing that. I read the intro, and if I like, I estimate how long it will take me with a full scroll to the bottom. I also read the bottom so I know the point we are working up to. Sometimes the article is too long and I skip an overly descriptive middle section.
      - bunderbunder 12y ago
        With complicated subjects sometimes you need to read the explanation a few times before it completely makes sense.
recursive 12y ago
It's probably because every blog post that contains the word "monad" becomes incomprehensible to most people that don't already know what they are. See also: curse of the monad
- the_af 12y ago
  This is not true. I learned about monads by reading websites about monads before I knew what they were. What other way is there to learn new things?
  - innguest 12y ago
    I think the curse alludes to the fact that no one tutorial does a good job at explaining monads, or they rarely do. It's true for me as it took me several tutorials to get the intuition for it and be able to revisit category theory tutorials (which at first seemed unwilling to give examples).
- GFischer 12y ago
  I had to look it up: http://www.i-programmer.info/news/167-javascript/5207-crockford-on-monads-and-gonads.html http://www.i-programmer.info/news/167-javascript/5207-crockf... "In addition to it begin useful, it is also cursed and the curse of the monad is that once you get the epiphany, once you understand - "oh that's what it is" - you lose the ability to explain it to anybody."
thinkpad20 12y ago
Yeah, I thought the same thing, once I saw val bind : ('a -> Result<'b,'c>) -> Result<'a,'c> -> Result<'b,'c> Because that's precisely the signature of bind (=<<) in Haskell. Although it looks nicer in Haskell. :P But I do respect the author's desire to avoid getting too mathy and hifalutin with the theoretical stuff, because you can really go overboard down that path...
- gamegoblin 12y ago
  The corresponding type signature in haskell is bind :: (a -> Either b c) -> Either a c -> Either b c So really you just save yourself a couple of angle brackets. That being said, the author does introduce the (>>=) function, but just doesn't say monad because that can turn people off really quickly.
  - nightski 12y ago
    I'd say it's the quotes that are noisy, not the angle brackets. But it's a minor nitpick, the F# one is fine.
  - thinkpad20 12y ago
    I was slightly mistaken, because I missed how the error type was put last in all of those Results. In Haskell, the error type is typically written first (Either MyError x), because since `Either a` is an instance of monad, we can replace `Either a` with `m` and get bind :: (a -> m b) -> m a -> m b Which is exactly the signature of (=<<). So you don't just get a cleaner syntax; you now have the ability to use `bind` with any monad (Maybe, List, IO, State...).
vertex-four 12y ago
As soon as bloggers try to use the word "monad", they have a tendency to go entirely off the rails into math-heavy definitions of things which many can't understand (for no reason!), or fail entirely to explain what a monad actually is and leave everyone more confused than when they started, which is exactly the thing that scares most people off of Haskell.
- TuringTest 12y ago
  IMO the best way to introduce monads to the average programmer is to say that they are a kind of functional design patterns (which is a valid analogy if not an exact categorization). DPs in object-oriented programming are also an abstract concept that is difficult to grasp at first, but most senior programmers have already gone through it and succeeded; so liking monads to them can inspire an initial sense of confidence that will be useful when learning the concept, and provides a useful frame to understand the purpose of using monads in functional code (which unfortunately is missing in most monad tutorials).
- the_af 12y ago
  Have you read Learn you a Haskell? The author is extremely didactic, introducing concepts and motivation before the jargon. I don't know what about monads feels scary to some people. They aren't actually that hard. There's stuff from C++ that scares the hell out of me, but I've seldom seen people arguing "let's not blog about this C++ feature, because it may scare readers away".
  - vertex-four 12y ago
    Frankly, even looking at various guides, I still can't really figure out how they work in Haskell, because there's no concrete step-by-step examples anywhere. I can't sit down and say "right, I have these two functions, one looks like `x = 1` and the next looks like `incr y = y+1`, what do I call on what to combine them with a monad, then how do I define a monad which only calls the latter if the former returns 1?", which should be the simplest case. Haskell's utterly ridiculous amount of syntactic sugar really doesn't help, and I figure its laziness probably doesn't either.
AnimalMuppet 12y ago
Because the author's point wasn't to give a monad tutorial or a monad analogy. The point was to illustrate a programming style. That style happens to be one use of a monad, but that wasn't the point. There are a whole bunch of us who are more pragmatic than theoretical. We care more about "that approach can simplify my code" than we care about "that's another instance of a monad".

bunderbunder 12y ago

> I'm not sure why the author goes out of his way to avoid saying "monad," Explained here: http://fsharpforfunandprofit.com/about/#banned http://fsharpforfunandprofit.com/about/#banned

slapresta 12y ago
So they decide to cripple themselves, intentionally restricting their knowledge to avoid being seen as pedantic? I could understand trying to avoid those words for beginners, but it doesn't seem like the site targets beginners only.
- andor 12y ago
  He explains how and why his code works. Adding too much formal terminology would make it seem like there is another layer of theory you need to grasp before you truly understand what's going on. Complicated terminology is elitist to beginners, because it nullifies first successes in understanding functional programming.
dons 12y ago
Because using sloppy language is so much better...
the_af 12y ago
I understand why they do it, but I think they're doing themselves a disservice. It's one thing to speak in jargon and wrongly assume your audience will follow you: "So this is obviously a catamorphism. This evidently a job for Kleisli arrows!". And a completely different thing is to construct a solution step by step, using familiar ideas, and then show that it can be seen as a monad, then give a brief explanation of why monads are useful and what motivates them. Which is exactly what the extremely didactic Learn you a Haskell site does (seriously: look at their example for the Writer Monad. It doesn't get more didactic and step-by-step than that) By avoiding the correct technical terms, they are: - Losing precision. - Failing to generalize the concept. - Underestimating their audience's ability to understand new concepts when property explained. The last one in particular kills me. I for one do not assume Visual Basic programmers are incapable or unwilling to learn new things.
- bunderbunder 12y ago
  If you're familiar with the psychological phenomenon known as priming, that may help help to explain the situation. For someone who's suffered through a few too many many blog posts that explain monads poorly, it is possible that simply mentioning the m-word, even in the very last sentence of the article, may inhibit their ability to comprehend the process. Because of that, there's a certain genius to the article's approach: Give folks who've been struggling with monads and arrows the best possible chance to grasp the concept without being encumbered by all the baggage that has built up around the terminology. If they do get the concept, great, and they're virtually guaranteed to realize shortly afterward, "Oh hey, forehead smack, those are monads!" (Incidentally, for people who've found themselves thrust into this unfortunate situation, a chapter titled A Fistful of Monads probably isn't likely to help much.) To that end, I'd even go so far as to say your worries about that last bullet point underestimate the audience's ability to understand new concepts when properly explained much worse than the author did.
  - steveklabnik 12y ago
    > even in the very last sentence of the article, I am not a psychologist, but isn't part of the definition of priming that it happens before? How would saying something afterwards harm your ability to previously understand something? Well, I guess I could see how that'd be possible, but I'm not sure that's priming anymore.
    - tlarkworthy 12y ago
      I don't read every article top to bottom, I would waste too much time doing that. I read the intro, and if I like, I estimate how long it will take me with a full scroll to the bottom. I also read the bottom so I know the point we are working up to. Sometimes the article is too long and I skip an overly descriptive middle section.
    - bunderbunder 12y ago
      With complicated subjects sometimes you need to read the explanation a few times before it completely makes sense.

recursive 12y ago

It's probably because every blog post that contains the word "monad" becomes incomprehensible to most people that don't already know what they are. See also: curse of the monad

the_af 12y ago
This is not true. I learned about monads by reading websites about monads before I knew what they were. What other way is there to learn new things?
- innguest 12y ago
  I think the curse alludes to the fact that no one tutorial does a good job at explaining monads, or they rarely do. It's true for me as it took me several tutorials to get the intuition for it and be able to revisit category theory tutorials (which at first seemed unwilling to give examples).
GFischer 12y ago
I had to look it up: http://www.i-programmer.info/news/167-javascript/5207-crockford-on-monads-and-gonads.html http://www.i-programmer.info/news/167-javascript/5207-crockf... "In addition to it begin useful, it is also cursed and the curse of the monad is that once you get the epiphany, once you understand - "oh that's what it is" - you lose the ability to explain it to anybody."

thinkpad20 12y ago

Yeah, I thought the same thing, once I saw val bind : ('a -> Result<'b,'c>) -> Result<'a,'c> -> Result<'b,'c> Because that's precisely the signature of bind (=<<) in Haskell. Although it looks nicer in Haskell. :P But I do respect the author's desire to avoid getting too mathy and hifalutin with the theoretical stuff, because you can really go overboard down that path...

gamegoblin 12y ago
The corresponding type signature in haskell is bind :: (a -> Either b c) -> Either a c -> Either b c So really you just save yourself a couple of angle brackets. That being said, the author does introduce the (>>=) function, but just doesn't say monad because that can turn people off really quickly.
- nightski 12y ago
  I'd say it's the quotes that are noisy, not the angle brackets. But it's a minor nitpick, the F# one is fine.
- thinkpad20 12y ago
  I was slightly mistaken, because I missed how the error type was put last in all of those Results. In Haskell, the error type is typically written first (Either MyError x), because since `Either a` is an instance of monad, we can replace `Either a` with `m` and get bind :: (a -> m b) -> m a -> m b Which is exactly the signature of (=<<). So you don't just get a cleaner syntax; you now have the ability to use `bind` with any monad (Maybe, List, IO, State...).

vertex-four 12y ago

As soon as bloggers try to use the word "monad", they have a tendency to go entirely off the rails into math-heavy definitions of things which many can't understand (for no reason!), or fail entirely to explain what a monad actually is and leave everyone more confused than when they started, which is exactly the thing that scares most people off of Haskell.

TuringTest 12y ago
IMO the best way to introduce monads to the average programmer is to say that they are a kind of functional design patterns (which is a valid analogy if not an exact categorization). DPs in object-oriented programming are also an abstract concept that is difficult to grasp at first, but most senior programmers have already gone through it and succeeded; so liking monads to them can inspire an initial sense of confidence that will be useful when learning the concept, and provides a useful frame to understand the purpose of using monads in functional code (which unfortunately is missing in most monad tutorials).
the_af 12y ago
Have you read Learn you a Haskell? The author is extremely didactic, introducing concepts and motivation before the jargon. I don't know what about monads feels scary to some people. They aren't actually that hard. There's stuff from C++ that scares the hell out of me, but I've seldom seen people arguing "let's not blog about this C++ feature, because it may scare readers away".
- vertex-four 12y ago
  Frankly, even looking at various guides, I still can't really figure out how they work in Haskell, because there's no concrete step-by-step examples anywhere. I can't sit down and say "right, I have these two functions, one looks like `x = 1` and the next looks like `incr y = y+1`, what do I call on what to combine them with a monad, then how do I define a monad which only calls the latter if the former returns 1?", which should be the simplest case. Haskell's utterly ridiculous amount of syntactic sugar really doesn't help, and I figure its laziness probably doesn't either.

AnimalMuppet 12y ago

Because the author's point wasn't to give a monad tutorial or a monad analogy. The point was to illustrate a programming style. That style happens to be one use of a monad, but that wasn't the point. There are a whole bunch of us who are more pragmatic than theoretical. We care more about "that approach can simplify my code" than we care about "that's another instance of a monad".