5 ms·

Everyone here is saying the article is wrong, but no one really adds anything or corrects the author. Can you expand?

by yelnatz 11y ago

theseoafs 11y ago
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.
kccqzy 11y ago
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.
- aninhumer 11y ago
  I'd prefer to use the Maybe monad as an example of not being able to extract a value, as it's far clearer that sometimes there is no such value. >Secondly the article says it needs a way to map a function over it. This is a functor not a monad. Yes, but since monad is a superclass of functor, it's still a necessary property. Certainly, I'd much prefer it be taught in that order, but this is definitely a property you need to understand in order to form intuitions about monads.
curun1r 11y ago
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.
- skc 11y ago
  >"The problem with monads is that truly understanding monads renders one completely incapable of explaining monads to anyone uninitiated"< This implies to me that no-one should be using them in code that is meant to be read by others
- aninhumer 11y ago
  I feel like you're overstating the problem, and I think that in itself is a good portion of the problem to start with. Monads have acquired this mystique that actively makes them harder for people to understand, because they don't have enough moving parts to satisfy people's expectations of a difficult concept. More often than not, the reaction of someone finally understanding monads is "Is that it?", and the answer is yes. There exist decent two reasonable pedagogies for learning monads, and good examples of them. The first is to teach people all the prerequisite concepts (HKT, typeclasses, Functors and Applicatives) properly, and then demonstrate a case where they're not quite enough, and you need a monad. Learn You A Haskell is a good example of this. The other is to discuss different examples of monads in non-monadic terms until people start to see the common pattern between use cases. As I understand it, this is the approach taken by You Could Have Invented Monads. And the final ingredient is just perseverance. I think at some point, all you can do is keep working until it clicks. Perhaps we'll eventually work out a pedagogy which avoids this, but for now all we can do is try to convince people they'll get it if they keep trying. Lots of people who don't consider themselves mathematical geniuses have managed it.

Everyone here is saying the article is wrong, but no one really adds anything or corrects the author. Can you expand?

by yelnatz 11y ago

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.

kccqzy 11y ago

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.

aninhumer 11y ago
I'd prefer to use the Maybe monad as an example of not being able to extract a value, as it's far clearer that sometimes there is no such value. >Secondly the article says it needs a way to map a function over it. This is a functor not a monad. Yes, but since monad is a superclass of functor, it's still a necessary property. Certainly, I'd much prefer it be taught in that order, but this is definitely a property you need to understand in order to form intuitions about monads.

curun1r 11y ago

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.

skc 11y ago
>"The problem with monads is that truly understanding monads renders one completely incapable of explaining monads to anyone uninitiated"< This implies to me that no-one should be using them in code that is meant to be read by others
aninhumer 11y ago
I feel like you're overstating the problem, and I think that in itself is a good portion of the problem to start with. Monads have acquired this mystique that actively makes them harder for people to understand, because they don't have enough moving parts to satisfy people's expectations of a difficult concept. More often than not, the reaction of someone finally understanding monads is "Is that it?", and the answer is yes. There exist decent two reasonable pedagogies for learning monads, and good examples of them. The first is to teach people all the prerequisite concepts (HKT, typeclasses, Functors and Applicatives) properly, and then demonstrate a case where they're not quite enough, and you need a monad. Learn You A Haskell is a good example of this. The other is to discuss different examples of monads in non-monadic terms until people start to see the common pattern between use cases. As I understand it, this is the approach taken by You Could Have Invented Monads. And the final ingredient is just perseverance. I think at some point, all you can do is keep working until it clicks. Perhaps we'll eventually work out a pedagogy which avoids this, but for now all we can do is try to convince people they'll get it if they keep trying. Lots of people who don't consider themselves mathematical geniuses have managed it.