

Monads for Normal Programmers - zachallaun
http://blog.jorgenschaefer.de/2013/01/monads-for-normal-programmers.html?m=1

======
monkeyfacebag
These "monad tutorials" drive me nuts. I wasted a week trying to understand
monads from random "You can do monads in Python, JavaScript and Brainfuck!"
tutorials that all had different (and sometimes inconsistent) perspectives on
what they were and what they were good for before I gave up and learned
Haskell. In my case, I was laboring under the false assumption that because I
knew language X, it would be easier to learn about monads in X than to learn
Haskell. In Haskell, the value of monadic computation falls out naturally from
the type system and syntax. Yes, you still have to verify the laws, but
Haskell's purity makes this easier as well.

I think the jQuery analogy has some didactic value for understanding
_combinators_ , but calling it a monad and falsely asserting that the laws
hold is not doing "normal programmers" any favors. In the comments, he
analogizes demonstrating the map function to C programmers, but this analogy
is false because he clearly understands map and what it's used for but the
same cannot be said for his understanding of monads.

For "normal programmers" out there who want to (for whatever reason) learn
about monads, my recommendation is to ignore these tutorials and learn Haskell
or an equivalent. I learned Haskell specifically to develop an understanding
of monads, but what I got out of it was much, much more valuable than just an
understanding of monads.

~~~
lmm
Having used them I came to the conclusion that the monad itself is just not a
useful concept; it's only when you're trying to do something that it makes
sense. I tried to write up my experiences as
<http://m50d.github.com/2013/01/16/generic-contexts.html> (very scala-
oriented), would be interested to hear whether that's useful to anyone.

~~~
runT1ME
Yes, that is a much better explanation of Monads. My experiences mirror yours.
Monads didn't make sense to me, while at the same time I was happily using
option and future and thinking how cool it was I could nest flatmap calls by
using the for syntax. Then one day.....

------
Peaker
> A Monad is an object whose methods return monads.

This is exceptionally wrong.

~~~
sophacles
This comment is exceptionally useless. Why is it wrong?

~~~
Peaker
It does not cover any of the interesting traits of Monads.

I could try to explain Monads in this comment, but others have already done it
well.

Any explanation of Monads must at least cover the actual Monadic operations
and the laws that relate them. Also, all of the examples he brings are not
actually Monads, as explained by others.

~~~
seliopou
> Any explanation of Monads must at least cover the actual Monadic operations
> and the laws that relate them. Also, all of the examples he brings are not
> actually Monads, as explained by others.

That's not true at all, and thinking like that is the reason why so many awful
monad tutorials exist, and everybody outside of the Haskell community
immediately tl;dr's when monads are mentioned.

You don't need to understand the monad laws to use monads. You _do_ need to
understand the monad laws implement your own monad. They are two completely
different levels of understanding, and there's nothing wrong with that.

~~~
Ixiaus
I respectfully disagree. It wasn't until I read the typeclassopedia and the
article on the Haskell category (that goes into the Monad laws, the Functor
laws, &c...) extensively did I really start to understand Monads.

At first, reading all of these "tuts" or "analogies" I always thought, "Oh!
It's just like an object in Python!" but boy was I wrong - no one told me I
was wrong, I just figured it out after reading the more formal presentations
of what a Monad is.

It was also mind opening to understand the basics of Category Theory and learn
that every Monad is a Functor.

------
misnome
The guide that I've looked at in the past and had success with is
[http://blog.sigfpe.com/2006/08/you-could-have-invented-
monad...](http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-
and.html) \- I got this from a prior HN post.

------
jonsterling
Craft of Christ, jQuery is not a monad. Ever since the first disgraceful post
to that effect, people have been spreading this utterly false rumor and
confusing the people they are supposed to be teaching.

------
jayferd
Uh, these are not monads. These are actually what we might call "wrappers".
They just provide a nicer interface for an underlying API (the DOM in jQuery's
case, and sql queries in Django's).

What _is_ a monad is JQuery.Deferred, with the `.then(...)` method as the
`bind` operator. This has to be monadic, because it wraps a promise of a value
that can't be computed synchronously.

~~~
MostAwesomeDude
More interestingly, the original Deferred, from the Twisted networking
library, is a monad and an arrow, and it passes the monad laws.

~~~
Peaker
It is similar to a Monad, but not quite, because the "bind" (addCallback)
mutates it inplace, and does not return a chained operation. Also because if
your callback's return _value_ is itself again a Deferred, it will flatten it
out. That means it "auto-joins" on the result so if you want to actually
result in some Deferred object in your callback you have to wrap it to
circumvent the flattening.

------
toolslive
The simplest starting point for C++/Java programmers is the question: "what if
the ';' was an infix operator that you can redefine?"

Then most of them start to understand the power of the concept.

~~~
ibotty
ah. the good old 'programmable semicolon' explanation. that is a good starting
point, yes.

(that's only a comment to make looking for these explanations easier.)

------
darkxanthos
If this is all there is to monads the functional community needs to level up
their communication experience and/or allow themselves to stop talking in
terms of type theory.

~~~
thirsteh
It's not. Please check out Edward Kmett's comments:

[http://blog.jorgenschaefer.de/2013/01/monads-for-normal-
prog...](http://blog.jorgenschaefer.de/2013/01/monads-for-normal-
programmers.html?showComment=1360280475215&m=1#c5160040403306778536)

[http://blog.jorgenschaefer.de/2013/01/monads-for-normal-
prog...](http://blog.jorgenschaefer.de/2013/01/monads-for-normal-
programmers.html?showComment=1360280760790&m=1#c3358986398956451459)

~~~
pacala
Edward talks about the monad laws, especially the associativity one. But that
is kind of simplistic, because the _domain_ over which the laws apply can be
shaped quite complexly, leading, for example, to IO or State being "monads". I
fail to see how the associativity law is very useful in reasoning about IO /
State. All I can see is that, syntactically, the parse tree (a; b;) c;
executes the same as a; (b; c;) under a left-most evaulation rule.

~~~
rapala
Associativity is very important in the case of IO. It guarantees that both

    
    
      (print a; print b;)print c;

and

    
    
      print a; (print b; print c;)

output _abc_.

~~~
pacala
Duh, blocks are evaluated in leftmost order. This is neither news, nor
particularly profound in any number of popular curly brace languages.
Rewritten with curly braces, so it's recognizable by most Blub programmers out
there:

    
    
        { { print a; print b; } print c; }
        { print a; { print b; print c; } }

~~~
crntaylor
The distinction is not important in an eagerly evaluating language, which
steps through its statements one by one and executes them as it finds them.

In a lazy, pure language it is of very great importance! With lazy evaluation
you get no guarantees as to what order your expressions are evaluated in.
Statements like "Blocks are evaluated in leftmost order" are just false in
Haskell.

Monads give you the ability to sequence your I/O actions _even though they are
still lazily evaluated_. This is why Haskell needs monads, and most other
languages get by without them.

~~~
takeoutweight
Another way to think of it is that monads are embedded into the operational
semantics of eager languages, so you that the programmer doesn't need to be
aware of them. After all, monads were initially used to formally describe the
behaviour of ML, an eager language, before they were used in Haskell.

------
donretag
He obviously did not read this article, which was popular on HN a few days
ago: [http://www.jasq.org/2/post/2013/01/the-mathematician-the-
mon...](http://www.jasq.org/2/post/2013/01/the-mathematician-the-monoid.html)

------
magsun
A monad is an object whose methods return: either itself if that method is not
meant to change the object's properties, like getters; or a new copy of
original monad object with changed properties if that method is meant to
change object properties, like setters.

~~~
runT1ME
no. String concatenation is not a monad.

~~~
groovy2shoes
Strings and concatenation do, however, form a monoid.

<http://en.wikipedia.org/wiki/Monoid>

~~~
thirsteh
A monoid is anything with an associative append and an identity operation. A
monad is a form of monoid (in the category of endofunctors; what's the
problem?), but monoids are not necessarily monads.

~~~
groovy2shoes
> A monoid is anything with an associative append and an identity operation.

It doesn't have to be an append, it can be any associative operation that is
closed over its domain and the domain features an identitiy element.

> A monad is a form of monoid (in the category of endofunctors; what's the
> problem?),

A _category theoretic_ monad may be a "monoid in the category of
endofunctors". The Monad type is not, strictly speaking, a monoid (but looks
like one if you squint a little).

> but monoids are not necessarily monads.

Who said they are? :)

~~~
thirsteh
It sounded like you were implying that they were, but the biggest thing they
have in common is that their names sound similar.

------
eranation
Here is (another) nice video about monads:
<http://vimeo.com/album/2206951/video/20717301>

------
Ingon
I think that monad is actually the "." in the OO world. This is because in my
view the monad actually sits in between the functions and controls the
function combinations and the value between the threading. So for instance
Maybe will decide whether to really call the next method based on the value
itself (like null). Or I maybe wrong :)

------
martinced
_"Monads for JavaScript Programmers"_

Just as the talk he refers to (I've seen it and it's ok)... It's for
JavaScript programmers):

<https://www.youtube.com/watch?v=b0EF0VTs9Dc>

So unless there's a 1-to-1 mapping between "Normal Programmers" and
"JavaScript" programmers this title is quite misleading.

~~~
VeejayRampay
And I wonder what "normal" programmers even means.

Is it "normal" as opposed to "exceptional/enlightened", to "anormal", to
"strange". Doesn't compute.

