This article is almost entirely wrong
Everyone here is saying the article is wrong, but no one really adds anything or corrects the author.
Can you expand?
Monads Explained Quickly
11–20 of 42 posts
Re: Monads Explained Quickly
#12This article is almost entirely wrong
Everyone here is saying the article is wrong, but no one really adds anything or corrects the author. Can you expand?
I don't know how to expand. The article is entirely wrong. I can't explain in a comment what's wrong with it because everything is wrong.
This article would barely be any less correct if it gave a recipe for pico de gallo and explained that that recipe defined a monad.
Re: Monads Explained Quickly
#13This article is almost entirely wrong
Everyone here is saying the article is wrong, but no one really adds anything or corrects the author. Can you expand?
Firstly the article says a monad needs to have a way to extract the value out of it. This is patently false. The most famous monad of all, the IO monad doesn't have a way to extract anything from it (notwithstanding evil trickery). Secondly the article says it needs a way to map a function over it. This is a functor not a monad. Being chainable is not overly important, as the functor law ensures that chained applications of fmap can be coalesced into a single one.
Re: Monads Explained Quickly
#14There are so many attempts at describing what monads are, but so few attempts at teaching why you would want to use a monad, and where it would be beneficial over other coding styles.
Re: Monads Explained Quickly
#15I would now think beginners are easily misled by Haskell's do notation. The <- syntax makes it looks like we are extracting values out of a monad, and the do notation certainly looks like it is chainable.
Re: Monads Explained Quickly
#16There are so many attempts at describing what monads are, but so few attempts at teaching why you would want to use a monad, and where it would be beneficial over other coding styles.
Monads basically capture computation itself: it gives you a way to describe a computation in terms of smaller computations arranged in a tree. I would recommend you to take a look at the history of monad in Haskell: why Haskell's initial approach of `main :: [Request] -> IO [Response]` doesn't work, and then perhaps you will appreciate why you want them at all.
Re: Monads Explained Quickly
#17There are so many attempts at describing what monads are, but so few attempts at teaching why you would want to use a monad, and where it would be beneficial over other coding styles.
At risk of adding to the pile of half baked pedagogy, here's my take at why they're useful. The operation to chain things together (denoted >>= and pronounced bind) in the Maybe monad has type
Maybe a -> (a -> Maybe b) -> Maybe b
Maybe bind(Maybe, Function>)
It's useful, because a popular alternative is to turn Maybe a into Maybe b by writing functions of type
Maybe a -> Maybe b
More generally, for monad m, >>= has type
m a -> (a -> m b) -> m b
It's no silver bullet, but it turns out to be a common pattern worth abstracting when you have structured data that you have to unpack and deal with in the same way over and over again. It's flexible too, but I won't go into that.
Re: Monads Explained Quickly
#18I appreciate the enthusiasm and the intent, but this is misleading. The maybe monad can be a wonderful abstraction, however the way used makes me think of something that can be expressed with applicative functors.
Re: Monads Explained Quickly
#19This article is almost entirely wrong
Everyone here is saying the article is wrong, but no one really adds anything or corrects the author. Can you expand?
The problem with monads is that truly understanding monads renders one completely incapable of explaining monads to anyone uninitiated. This seems to be the most fundamental property of the monad.
It seems, from the plethora of monad explanation articles that get posted here, that many people, in their hubris, think they've learned monads and think that they will succeed where so many others have failed and come up with the first approachable explanation of monads. These explanations fall into one of two categories, either the explainer has truly learned monads and offers up an explanation that's correct but entirely confusing to anyone who doesn't already understand the concept. Or, as in this case, the explainer hasn't actually understood monads and offers up an explanation that is, indeed, approachable to someone learning monads but is, never the less, incorrect.
In these cases, it does no good for those who understand monads to try to explain where the explanation fails. Because as people who understand monads, their explanation will surely cause far more confusion than it will address. It is therefore all that they can do to simply point out that the explanation is wrong and that we're still waiting for the one true approachable way of learning monads.
Re: Monads Explained Quickly
#20There are so many attempts at describing what monads are, but so few attempts at teaching why you would want to use a monad, and where it would be beneficial over other coding styles.
At risk of adding to the pile of half baked pedagogy, here's my take at why they're useful. The operation to chain things together (denoted >>= and pronounced bind) in the Maybe monad has type Maybe a -> (a -> Maybe b) -> Maybe b In a more a java-like notation, this is like Maybe bind(Maybe , Function >) The Haskell notation says that it's a function that takes two arguments (separated by ->). The first argument (May…
I really have to thank you for this comment. I had serious trouble understanding Haskell's type notation, and translating it to Java-ish was immensely helpful.