I was glad when the author of the article advised against learning Monads by analogy, because it's one of those subjects where analogies serve only to confuse people. Personally, my brain maps badly to Haskell syntax, so let's do this in JavaScript (I know, I know, not so powerful and everything):
In fact if you used jQuery, you already know what a Monad is, probably without realizing it. Consider the following code:
You can follow along what this code does by following the dots. First, all elements matching the ".myelements" class are returned, these are then filtered, and the result of that gets a css modification.
Every time you wrote a method that returns an object, you already did monads in principle. They can be used to chain things together. While Haskell provides semantics that explicitly deal with the mechanics of monads, pretty much every dynamic language has them.
Here's what it looks like in PHP, for example:
$obj
->bla()
->beep()
->borp();
You can use monads to make your code more concise, to simply chain function calls, or to iterate over a list, but they're also often used when sifting through databases since filtering and applying attributes to items. For example, an SQL-like database query might be expressed like this:
Of course, that's an API which is a bit dishonest since it acts as if the code really goes through all those items (which would be a performance disaster with huge databases), so when you see something like this it's often just a shortcut to assemble a query. And this goes for monads in general, they're really more of an API style. A monad itself is an abstract concept, a paradigm.
> Also, it's suspicious that pg has never once mentioned monads
For a theory why pg specifically hasn't written anything about monads yet, here's an article that I believe was on HN in the past about the difficulties of comfortably using monads in Lisp: http://marijnhaverbeke.nl/monad.html - but I guess the short explanation would probably be that Lispers tend to deal with monad-worthy problems in other ways.
While there might be some structural similarity of function chaining to bind operators in Haskell, jQuery isn't a monad. The burden of proof for being a monad is explicitly demonstrating adherence to the monad laws. To quote prolific Haskeller Don Stewart "I am pretty skeptical that the jQuery API as a whole could satisfy the monad laws".
I'm replying to you, but this comment is intended for freyrs3 as well.
> No, you have a completely incorrect understanding of Monads.
To re-use your slightly ad-hominem argument structure: "No, you have a completely incorrect understanding of Monads!" Of course the word "completely" here is just an unnecessarily flamebaity word choice in describing either of us. Clearly, we both have some understanding of monads. Let's look at the facts instead:
A functor applies an operation to a wrapped value. But monads apply functions that also return a wrapped value. It should be easy to see why people think the jQuery chain pattern is indeed monadic.
For what it's worth, I'm far from alone in asserting that jQuery is indeed a monad.
Since Haskell people claim to be the only enablers of "true monads", they would of course nitpick about patterns implemented in other languages. But religion aside, the OP asked for the possible uses of monads, and there they are. That the example also shows functors is just an added benefit, though not at all relevant to the discussion.
> For what it's worth, I'm far from alone in asserting that jQuery is indeed a monad.
And a lot of people think that the reason astronauts float on the ISS is because there's no gravity there.
> Since Haskell people claim to be the only enablers of "true monads", they would of course nitpick about patterns implemented in other languages.
Yes, because monad is an actual term and calling something a monad just because it sort of looks like it if you squint doesn't make it one. You can't write return in the 'jQuery monad', because there's no way to wrap arbitrary data types, only things like DOM elements. Something like a promise is closer to a monad, because you can turn any value into a promise, but IIRC there are still issues around it that I don't remember offhand.
So I don't particularly feel like watching an entire hour-long video about something I'm already very familiar with for the sake of an argument on the internet; I'm just going to skim the video and look at the slides.
He describes monads as "a loophole" in the idea of function purity. This isn't true; monads aren't a way to 'cheat' any more than passing an accumulator through like
is. He says something about state and functions and closures that I can't understand and how the state is 'always different', and it's just nonsense as far as I can tell.
He also calls values 'monads', which isn't accurate terminology at all; they're usually called monadic actions.
Again, jQuery or any arbitrary API is not an monadic until one shows that the monad laws hold for it. It doesn't matter how many people assert it to be true, whether an API is monadic is mechanically provable fact and as of yet there is no proof that jQuery is monadic.
Just because lots of people think jQuery is a monad doesn't make it true. Also, even if you're not interested in that high level of anal-retentive precision in your terminology, I would argue that's still not the main point of monads. I talk about this more in the vimeo presentation linked in my other comment here.
>But monads apply functions that also return a wrapped value.
Yes, but they also must follow the monad laws.
>It should be easy to see why people think the jQuery chain pattern is indeed monadic.
It is not easy for me to see. In any of your examples are you returning the same encapsulated structure in your lambda you pass in? It doesn't look like it.
>For what it's worth, I'm far from alone in asserting that jQuery is indeed a monad.
Yes, a lot of people have a misunderstanding of monads.
>Since Haskell people claim to be the only enablers of "true monads",
I'm not a Haskell person. I write monadic code in both Scala and C# to great effect.
In fact if you used jQuery, you already know what a Monad is, probably without realizing it. Consider the following code:
You can follow along what this code does by following the dots. First, all elements matching the ".myelements" class are returned, these are then filtered, and the result of that gets a css modification.Every time you wrote a method that returns an object, you already did monads in principle. They can be used to chain things together. While Haskell provides semantics that explicitly deal with the mechanics of monads, pretty much every dynamic language has them.
Here's what it looks like in PHP, for example:
You can use monads to make your code more concise, to simply chain function calls, or to iterate over a list, but they're also often used when sifting through databases since filtering and applying attributes to items. For example, an SQL-like database query might be expressed like this: Of course, that's an API which is a bit dishonest since it acts as if the code really goes through all those items (which would be a performance disaster with huge databases), so when you see something like this it's often just a shortcut to assemble a query. And this goes for monads in general, they're really more of an API style. A monad itself is an abstract concept, a paradigm.> Also, it's suspicious that pg has never once mentioned monads
For a theory why pg specifically hasn't written anything about monads yet, here's an article that I believe was on HN in the past about the difficulties of comfortably using monads in Lisp: http://marijnhaverbeke.nl/monad.html - but I guess the short explanation would probably be that Lispers tend to deal with monad-worthy problems in other ways.