4 ms·

I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.

Sharlin 8y ago
For better or worse, "container" is the most intuitive concept to use when trying to explain monads. Yes, there are monad instances that don't really fit the container model, but they're not important at first. Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados. However, I agree that the important step in understanding monads as an abstraction is realizing how map and flatmap make sense for many things other than lists.
- pas 8y ago
  I guess flatMap is very misleading to newcommers. Probably simply calling it chaining, composition, or even "then" would help.
  - Sharlin 8y ago
    That's true, although it's better than "bind".
  - sullyj3 8y ago
    I like chaining, that's a good analogy. I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as impenetrable symbol soup. I don't know whether I'd endorse trying to use an intuitive mnemonic like this to explain monads to FP beginners.
    - pas 8y ago
      I know a lot of symbols, but I still get irritated when I encounter a new one, and I can't search for it. (At least math got a nice list: https://en.wikipedia.org/wiki/List_of_mathematical_symbols https://en.wikipedia.org/wiki/List_of_mathematical_symbols ) For math it's kind of okay. Because there the point is to talk about that theory. You introduce definitions, and theorems, and use them in proofs. Or in calculations. And even in math proofs usually come with a lot of explanation. (At least the better ones.) In software engineering maintainability is important. And, sure, we can just accept that Haskell is something that you can't learn by looking at real world Haskell code. After all, you can't really learn real world "research math" by looking at it. But I think real world code, especially one that is looking for maintainers should not err on the side of indecipherability and inapproachability. I continue to chastise Scalaz for its bad naming and documentation convention. (Haskell is ... well, it's irredeemable.) And TypeScript is getting into this mess too. The documentation for new releases with new type system goodies (and I really mean it, I like powerful type systems, I just don't want to spend my life on understanding them, I'm happy to use them to get particular jobs done), but with barely enough documentation to let serious TS users with many years of experience understand it.
- sullyj3 8y ago
  > Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados. Thank-you for crystallizing and articulating a frustration I have often, as a beginner to intermediate Haskeller.
pas 8y ago
They have something in them (sometimes just a very fuzzy non-explicit state, maybe a seed for a RNG, but there's something there, otherwise it'd be just a value). Every monad is a [type] constructor, wrapping something. Or could you show a counterexample please?

For better or worse, "container" is the most intuitive concept to use when trying to explain monads. Yes, there are monad instances that don't really fit the container model, but they're not important at first. Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados. However, I agree that the important step in understanding monads as an abstraction is realizing how map and flatmap make sense for many things other than lists.

pas 8y ago
I guess flatMap is very misleading to newcommers. Probably simply calling it chaining, composition, or even "then" would help.
- Sharlin 8y ago
  That's true, although it's better than "bind".
- sullyj3 8y ago
  I like chaining, that's a good analogy. I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as impenetrable symbol soup. I don't know whether I'd endorse trying to use an intuitive mnemonic like this to explain monads to FP beginners.
  - pas 8y ago
    I know a lot of symbols, but I still get irritated when I encounter a new one, and I can't search for it. (At least math got a nice list: https://en.wikipedia.org/wiki/List_of_mathematical_symbols https://en.wikipedia.org/wiki/List_of_mathematical_symbols ) For math it's kind of okay. Because there the point is to talk about that theory. You introduce definitions, and theorems, and use them in proofs. Or in calculations. And even in math proofs usually come with a lot of explanation. (At least the better ones.) In software engineering maintainability is important. And, sure, we can just accept that Haskell is something that you can't learn by looking at real world Haskell code. After all, you can't really learn real world "research math" by looking at it. But I think real world code, especially one that is looking for maintainers should not err on the side of indecipherability and inapproachability. I continue to chastise Scalaz for its bad naming and documentation convention. (Haskell is ... well, it's irredeemable.) And TypeScript is getting into this mess too. The documentation for new releases with new type system goodies (and I really mean it, I like powerful type systems, I just don't want to spend my life on understanding them, I'm happy to use them to get particular jobs done), but with barely enough documentation to let serious TS users with many years of experience understand it.
sullyj3 8y ago
> Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados. Thank-you for crystallizing and articulating a frustration I have often, as a beginner to intermediate Haskeller.

pas 8y ago

They have something in them (sometimes just a very fuzzy non-explicit state, maybe a seed for a RNG, but there's something there, otherwise it'd be just a value). Every monad is a [type] constructor, wrapping something. Or could you show a counterexample please?