Monads for Normal Programmers

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

by zachallaun • 13 years ago

53 45 13 years ago

blog.jorgenschaefer.de

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.

thirsteh3• 13 years ago

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

http://blog.jorgenschaefer.de/2013/01/monads-for-normal-prog...

pacala2• 13 years ago

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.

dons• 13 years ago

> A Monad is an object whose methods return monads.

Is a truly terrible "definition". It is not a constructive definition. You can't implement anything with this.

Mostly this article is about combinator libraries -- where bind is function application. Nothing to do with monadic bind.

tel• 13 years ago

It is very far from all there is to monads. It's very roughly a small programming pattern which is inspired by how some people use monads.

svachalek• 13 years ago

As he points out in his introduction, the first rule of monads is that everyone else's description of monads is wrong.

It appears that all you can do is share the mathematical description of a monad (and not the way it is declared in Haskell which also appears to be universally accepted to be wrong). All further abstraction, description, and communication are approximately equivalent to debates on religion.

I have a deep suspicion that this quality makes Haskell essentially write-only at scale.

tikhonj• 13 years ago

I'm not quite sure what you mean: monads are very well defined even within Haskell, certainly more than most programming abstractions. Essentially, a monad is any type that has some particular functions defined on it that act consistently with each other (e.g. follow the monad laws). That is all a monad is--understanding what they're useful for or why we care is a different story, but you can get that from examples.

You can have a perfectly good grasp of monads in Haskell without understanding the mathematics behind it at all: the a look at the "you could have invented monads"[1] tutorial.

[1] http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

Moreover, the behavior of monads is more precisely proscribed than the behavior of abstractions used in other languages. While you do not need to understand the mathematical background to use monads, the fact that's it's there helps ensure that implementations act consistently. Having explicit laws implementations must follow makes it much easier to rely on them.

So monads are actually very well defined, even if too many people rush out to write ill-advised blog posts before they actually understand anything (this post is a great example, as is the linked talk by Douglas Crockford).

Ultimately, I think Haskell is the language that works best at scale. It both gives you the tools you need to write extremely maintainable code and also actively encourages you to do that. I've found Haskell code to be significantly simpler, more self-contained, more decoupled and more self-documenting than any other language I've used. I've found it far easier to come back to Haskell code I left months ago than to come back to Python out JavaScript or Java code, by a fair margin.

Peaker5• 13 years ago

> A Monad is an object whose methods return monads.

This is exceptionally wrong.

sophacles2• 13 years ago

This comment is exceptionally useless. Why is it wrong?

johnbender• 13 years ago

This is a vast oversimplification of both Haskell's monads and the category theoretic Monad. Just because you can chain methods doesn't make something a Monad even in the most basic sense of satisfying the typeclass requirements in Haskell.

Peaker5• 13 years ago

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.

steveklabnik2• 13 years ago

    class Monad
      def foo
        return Monad.new
      end
    end

is a monad by the article, but is certainly not a monad.

EDIT: s/unit/foo/, to remove discussion about comparisons to the 'unit' that monads actually have.

misnome• 13 years ago

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... - I got this from a prior HN post.

donretag• 13 years ago

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...

monkeyfacebag• 13 years ago

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• 13 years ago

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.

runT1ME2• 13 years ago

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.....

nicktelford• 13 years ago

Couldn't agree more. I read somewhere (I forget where): "You don't need to learn Category Theory in order to learn Haskell. Learn Haskell, and you'll develop an intuition for Category Theory as a side-effect."

I think the best "Monad tutorial" is Learn You A Haskell For Great Good[1], in its entirety.

[1] http://learnyouahaskell.com/

toolslive• 13 years ago

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• 13 years ago

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.)

martinced• 13 years ago

"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• 13 years ago

And I wonder what "normal" programmers even means.

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

eranation• 13 years ago

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

jonsterling• 13 years ago

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.

jneen• 13 years ago

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• 13 years ago

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

Peaker5• 13 years ago

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.

magsun• 13 years ago

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.

runT1ME2• 13 years ago

no. String concatenation is not a monad.

groovy2shoes2• 13 years ago

Strings and concatenation do, however, form a monoid.

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

Ingon• 13 years ago

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 :)

Monads for Normal Programmers

Related Stories