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.
http://blog.jorgenschaefer.de/2013/01/monads-for-normal-prog...
http://blog.jorgenschaefer.de/2013/01/monads-for-normal-prog...
(print a; print b;)print c; print a; (print b; print c;)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.
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.
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 :)
This is exceptionally wrong.
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.
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.
class Monad
def foo
return Monad.new
end
end
EDIT: s/unit/foo/, to remove discussion about comparisons to the 'unit' that monads actually have.
class Monad:
def __init__(self, val):
self.val = val
unit = __init__
def bind(self, fun):
return fun(self.val)
But interestingly we could implement lift as a Monad method by:
def lift(self, fun=lambda x: x*2):
self.val = fun(self.val)
return self
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.
I think the best "Monad tutorial" is Learn You A Haskell For Great Good[1], in its entirety.
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.
Then most of them start to understand the power of the concept.
(that's only a comment to make looking for these explanations easier.)
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.
Is it "normal" as opposed to "exceptional/enlightened", to "anormal", to "strange". Doesn't compute.