4 ms·

The concept itself is extremely useful (in a programming language like Haskell, at least), but for whatever reason it resists understanding in the way most peop

by dack 5y ago

The concept itself is extremely useful (in a programming language like Haskell, at least), but for whatever reason it resists understanding in the way most people want to teach it. I'm not sure why it's different than other programming concepts in this way... maybe just because it's such an abstract concept where most people have no frame of reference. You don't appreciate it until you've used it in a bunch of different contexts and finally see why this one abstraction works for all of them

foldr 5y ago
I feel that a certain segment of the Haskell community doesn't help matters by pretending that monads (in the Haskell sense) have something interesting to do with category theory. Fundamentally, a monad (in Haskell) is just a set of operators that obey some simple algebraic laws. These laws can be illustrated with simple examples, and don't require any deep mathematical knowledge to comprehend. If you really want to, you can use the language of category theory to talk about monads in Haskell. Some people seem to get a great deal of satisfaction out of doing so (and I suppose that it's harmless fun). But it does build up a certain undeserved mystique around monads in Haskell.
- aesyondu 5y ago
  > These laws can be illustrated with simple examples, and don't require any deep mathematical knowledge to comprehend. If you could share some of these examples, or perhaps a link to those examples, I'd greatly appreciate it.
  - kaba0 5y ago
    I wrote an explanation for them here: https://news.ycombinator.com/item?id=28844533 https://news.ycombinator.com/item?id=28844533 Though I’m not the best at explaining things, hopefully it makes sense.
    - aesyondu 5y ago
      Oh okay. So what I'm understanding from your post is that, a monad is just a way of applying the return value of one function as a parameter for another function. Sorry if I misunderstood. I've been reading many explanations for monads, but insight seem to elude me.
      - kaba0 5y ago
        Well, mostly - but I think this wrapping of things is the more important part, allowing us to manipulate the inner things without actually being able to touch those. For example, mapping some function over a Result type that may or may not have a value in an iterative manner would make me check for the existence of the value, unpack, and apply function. If we have a Monad abstraction then I can just map my function which will be applied in case of a result, or the whole thing will remain None - it is safe either way. And one other useful part is the uniformity of functions working on monads - I can use the same ones for a List, Result, or any similar container, IO, State monads and even Async is a monad.
  - foldr 5y ago
    The explanation on the Haskell Wiki isn’t too obscure (if you already know Haskell) and has examples: https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws
- marcosdumay 5y ago
  Interpreter patterns are always hard to understand, in any paradigm. It's a combination of newcomers having no idea why one would use them, they being completely meta and unrelated to the final problems, and all the explanation available being trivial about how they are constructed or completely handwavy about all the ways one could use it. It's just that on other paradigms interpreters are a very advanced and completely optional topic. While on pure FP they are fundamental.

by dack 5y ago

foldr 5y ago

I feel that a certain segment of the Haskell community doesn't help matters by pretending that monads (in the Haskell sense) have something interesting to do with category theory. Fundamentally, a monad (in Haskell) is just a set of operators that obey some simple algebraic laws. These laws can be illustrated with simple examples, and don't require any deep mathematical knowledge to comprehend. If you really want to, you can use the language of category theory to talk about monads in Haskell. Some people seem to get a great deal of satisfaction out of doing so (and I suppose that it's harmless fun). But it does build up a certain undeserved mystique around monads in Haskell.

aesyondu 5y ago
> These laws can be illustrated with simple examples, and don't require any deep mathematical knowledge to comprehend. If you could share some of these examples, or perhaps a link to those examples, I'd greatly appreciate it.
- kaba0 5y ago
  I wrote an explanation for them here: https://news.ycombinator.com/item?id=28844533 https://news.ycombinator.com/item?id=28844533 Though I’m not the best at explaining things, hopefully it makes sense.
  - aesyondu 5y ago
    Oh okay. So what I'm understanding from your post is that, a monad is just a way of applying the return value of one function as a parameter for another function. Sorry if I misunderstood. I've been reading many explanations for monads, but insight seem to elude me.
    - kaba0 5y ago
      Well, mostly - but I think this wrapping of things is the more important part, allowing us to manipulate the inner things without actually being able to touch those. For example, mapping some function over a Result type that may or may not have a value in an iterative manner would make me check for the existence of the value, unpack, and apply function. If we have a Monad abstraction then I can just map my function which will be applied in case of a result, or the whole thing will remain None - it is safe either way. And one other useful part is the uniformity of functions working on monads - I can use the same ones for a List, Result, or any similar container, IO, State monads and even Async is a monad.
- foldr 5y ago
  The explanation on the Haskell Wiki isn’t too obscure (if you already know Haskell) and has examples: https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws
marcosdumay 5y ago
Interpreter patterns are always hard to understand, in any paradigm. It's a combination of newcomers having no idea why one would use them, they being completely meta and unrelated to the final problems, and all the explanation available being trivial about how they are constructed or completely handwavy about all the ways one could use it. It's just that on other paradigms interpreters are a very advanced and completely optional topic. While on pure FP they are fundamental.