Hacker News Reader

Comment by darkxanthos | Hacker News Reader

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.

View on HN

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

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

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

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.

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.

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; } }

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.

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.

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.

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.

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.

> Ultimately, I think Haskell is the language that works best at scale.

While i agree on that, i think it depends on what one means with "at scale". I've seen that phrase used to mean something like "having a humongous team of 50+ developers and being able to add 50+ new (preferably cheap) developers (who might not be very well versed in the technology nor the business that we're working on) at any time and make them write code right out of the bat". I think Haskell would not fit very well with that "work at scale" definition :)

Reply on news.ycombinator.com