5 ms·

> The incomprehension of the newbies is matched in intensity only by the smugness of the experts. Oh good. A write up that’s aware of how unapproachable monad

> The incomprehension of the newbies is matched in intensity only by the smugness of the experts. Oh good. A write up that’s aware of how unapproachable monads seem. Maybe this will actually be a good, plain-English breakdown. Four paragraphs later: > Monads, as a mathematical concept, can be always used as a part of the semantic model, but whether they transpire into the type system of the object language is a matter of design choice. Oh... well, never mind.

Analemma_ 8y ago
"Monads are just monoids in the category of endofunctors, what's the problem?"
nicoburns 8y ago
> Oh good. A write up that’s aware of how unapproachable nomads seem. Normally I don't comment on typos (there are more important things in life!), but this one made me chuckle :)
- thanatos_dem 8y ago
  Sorry, fixed. That’s what I get for using my phone to comment on technical things :)
rhencke 8y ago
The best practical description of monads I've heard, with apologies as I do not remember the quote's author: What if, in C++, the semicolon was an operator you could overload?
- willtim 8y ago
  I've heard Phil Wadler use this description. Why is it useful? To implement Async/Await as a library instead of a language change. Mainstream languages like C# are looking more and more like a collection of DSLs and less like a general purpose language (!).
- edflsafoiewq 8y ago
  In C++ the semicolon separates statements. The appropriate correspondence is the comma operator, which separates values and, of course, you can overload the comma operator (much to our general chagrin) so this doesn't seem very enlightening. But this is still only discussing >>, not >>=.
- FPGAhacker 8y ago
  So I haven’t quite grasped monads or their usefulness. Your “what-if” is completely meaningless to me, and I’m sure it’s my lack. Could you expound upon the implications? To me it is like saying: what if you could redefine the period at the end of a sentence....ok, but why?
  - white-flame 8y ago
    To my limited non-Haskellian understanding, you can give a block of expressions to a monad. It then decides which expressions to evaluate, in which order, optionally depending on the value they might return to the monad. So you could have a monad which does "evaluate all these in order unless something goes null" (which is a nuisance to type in C-style languages), or one that expands on the if-then-else concept. None of these carry forward internal/hidden state like an IO monad does, but are there to expand user control for how to flow from 1 expression to another in your custom scopes. It's somewhat conceptually related to Command or Visitor Pattern programming, but Haskell has syntactic sugar to have them basically work similarly to normal statements. Alternatively, this is a runtime-only version of one specific thing that Lisp macros can do to &body scopes, in constructing custom control flow. This also is only 1 way to use monads, as they're a technically pretty simple tool (an interface with 2 functions) that can be used in a bunch of scenarios. [If I'm wrong, and I'm probably wrong, I'd love clarifications for myself, too!]
  - v_lisivka 8y ago
    Monads are easy to understand for imperative programmers. Imagine, you have code "var a=new A(); a.foo(x); a.bar(y); print(a);". How you reimplement it when "a" is readonly structure, not even a object? You will need to implement functions "foo(a, x) -> a" "bar(a, y) -> a", and so on. If you do so, you will have monad.
    - AnimalMuppet 8y ago
      What's not so easy to understand for an imperative programmer is this: Why should I jump through those hoops just to have a readonly structure? Why not just, you know, program imperatively? I think this is a big part of the problem explaining monads. If you don't have the problem, you don't care about the solution. And if you're an imperative programmer, this looks like saddling yourself with a problem you don't need to have, and then jumping through bizarre hoops to deal with the complications caused by a set of restrictions that you didn't need in the first place. I think instead the right approach is to sell people on the benefits of immutability, and talk much less about monads. When they start to need them, they'll start to see why they want them. Once they see them solve some problems that they actually have, then they'll start to get it.
- Wildgoose 8y ago
  That's how I describe monads - a programmable semicolon. Basically {A; B} becomes semicolon(A, B). Then you can have hidden state in the semicolon function and have complete control of how (and whether) you execute A and B, and in what order.
alipang 8y ago
Here's a tutorial with a focus on more practical applications that doesn't try to go too deep into the semantics of monads, but rather tries to build intuition on a syntactic/language level - which I think is generally more helpful for beginners. https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit...
- willtim 8y ago
  Also the original paper by Phil Wadler - it is very readable: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...
Jaxan 8y ago
Well, then you came pretty far already. This post is not a tutorial on monads. It’s really his thoughts on why he sees monads are needed in Haskell. (And not needed in, for example, ML.)
cageface 8y ago
Explanations of monads in the abstract always make my eyes glaze over. But if you look at a few examples of actual applications of monads I think the concept shines through clearly enough.

Analemma_ 8y ago

"Monads are just monoids in the category of endofunctors, what's the problem?"

nicoburns 8y ago

> Oh good. A write up that’s aware of how unapproachable nomads seem. Normally I don't comment on typos (there are more important things in life!), but this one made me chuckle :)

thanatos_dem 8y ago
Sorry, fixed. That’s what I get for using my phone to comment on technical things :)

rhencke 8y ago

The best practical description of monads I've heard, with apologies as I do not remember the quote's author: What if, in C++, the semicolon was an operator you could overload?

willtim 8y ago
I've heard Phil Wadler use this description. Why is it useful? To implement Async/Await as a library instead of a language change. Mainstream languages like C# are looking more and more like a collection of DSLs and less like a general purpose language (!).
edflsafoiewq 8y ago
In C++ the semicolon separates statements. The appropriate correspondence is the comma operator, which separates values and, of course, you can overload the comma operator (much to our general chagrin) so this doesn't seem very enlightening. But this is still only discussing >>, not >>=.
FPGAhacker 8y ago
So I haven’t quite grasped monads or their usefulness. Your “what-if” is completely meaningless to me, and I’m sure it’s my lack. Could you expound upon the implications? To me it is like saying: what if you could redefine the period at the end of a sentence....ok, but why?
- white-flame 8y ago
  To my limited non-Haskellian understanding, you can give a block of expressions to a monad. It then decides which expressions to evaluate, in which order, optionally depending on the value they might return to the monad. So you could have a monad which does "evaluate all these in order unless something goes null" (which is a nuisance to type in C-style languages), or one that expands on the if-then-else concept. None of these carry forward internal/hidden state like an IO monad does, but are there to expand user control for how to flow from 1 expression to another in your custom scopes. It's somewhat conceptually related to Command or Visitor Pattern programming, but Haskell has syntactic sugar to have them basically work similarly to normal statements. Alternatively, this is a runtime-only version of one specific thing that Lisp macros can do to &body scopes, in constructing custom control flow. This also is only 1 way to use monads, as they're a technically pretty simple tool (an interface with 2 functions) that can be used in a bunch of scenarios. [If I'm wrong, and I'm probably wrong, I'd love clarifications for myself, too!]
- v_lisivka 8y ago
  Monads are easy to understand for imperative programmers. Imagine, you have code "var a=new A(); a.foo(x); a.bar(y); print(a);". How you reimplement it when "a" is readonly structure, not even a object? You will need to implement functions "foo(a, x) -> a" "bar(a, y) -> a", and so on. If you do so, you will have monad.
  - AnimalMuppet 8y ago
    What's not so easy to understand for an imperative programmer is this: Why should I jump through those hoops just to have a readonly structure? Why not just, you know, program imperatively? I think this is a big part of the problem explaining monads. If you don't have the problem, you don't care about the solution. And if you're an imperative programmer, this looks like saddling yourself with a problem you don't need to have, and then jumping through bizarre hoops to deal with the complications caused by a set of restrictions that you didn't need in the first place. I think instead the right approach is to sell people on the benefits of immutability, and talk much less about monads. When they start to need them, they'll start to see why they want them. Once they see them solve some problems that they actually have, then they'll start to get it.
Wildgoose 8y ago
That's how I describe monads - a programmable semicolon. Basically {A; B} becomes semicolon(A, B). Then you can have hidden state in the semicolon function and have complete control of how (and whether) you execute A and B, and in what order.

alipang 8y ago

Here's a tutorial with a focus on more practical applications that doesn't try to go too deep into the semantics of monads, but rather tries to build intuition on a syntactic/language level - which I think is generally more helpful for beginners. https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit...

willtim 8y ago
Also the original paper by Phil Wadler - it is very readable: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...

Jaxan 8y ago

Well, then you came pretty far already. This post is not a tutorial on monads. It’s really his thoughts on why he sees monads are needed in Haskell. (And not needed in, for example, ML.)

cageface 8y ago

Explanations of monads in the abstract always make my eyes glaze over. But if you look at a few examples of actual applications of monads I think the concept shines through clearly enough.