7 ms·
Monads Explained Quickly
- 4a3f35b5a 11y ago"Monads Explained Quickly, But Mostly Incorrectly" would be a better name. Isn't what's defined here mostly just a functor?
- nitrix 11y agoHalf of a functor and half a (co)monad; it's very misleading and will just increase the general confusion around monads for beginners. Even when you think you figured it out, it's just one part of the puzzle too. I'd stay away from anything self-described as "quickly" or "the hard way".
- deleted 11y ago[deleted]
- theseoafs 11y agoThis article is almost entirely wrong
- yelnatz 11y agoEveryone here is saying the article is wrong, but no one really adds anything or corrects the author. Can you expand?
- theseoafs 11y agoI 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 agoFirstly 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 agoI'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 agoThe 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 agoI 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.
- finnyspade 11y agoWouldn't it be (with a little runtime typechecking): function IdentityMonad(v) { this._v = v; } IdentityMonad.prototype.bind = function(f) { var o = f(this._v); if(!(o instanceof IdentityMonad)){ throw new Error("function must return IdentityMonad"); } return o; }
- imh 11y agoSome things are easier to learn by doing. These exercises (https://mightybyte.github.io/monad-challenges/ https://mightybyte.github.io/monad-challenges/) are what made it stick for me.
- striking 11y agoStop explaining monads. There are two ways to approach them. One is by doing. The other is by math. If you can't understand how "monads are monoids in the category of endofunctors", you should try learning by doing. Don't try reading about it, don't try reasoning about it. Just do it. EDIT: okay, I'll explain. Haskell et al. have this really neat propensity to abstract well. That means that very many concepts (Promises, null types, etc.) can actually be abstracted into one concept (the Monad) because they all have the same behavior except for a couple of points. You won't believe me, but that's exactly it. To explain "what monads are" you must explain everything (or most things) that monads can do. Save yourself the time. Don't read or write such a thing. They're so general and so abstract as to be totally meaningless without understanding what they're built on (either in the PL/doing direction or in the mathematical/conceptual direction).
- mrkgnao 11y agoWell, that oft-maligned definition is actually what made it stick for me . . .
- striking 11y agoRight, the math does work for some people! But you have to have a mathematical background that's fairly hard to come across (category theory is pretty far from most people's reach and rarely applied except in PL and algo study)
- aninhumer 11y ago>The other is by math. If you can't understand how "monads are monoids in the category of endofunctors" I don't think you need to understand that in order to have a more abstract understanding of Monads. Just go read the Monad typeclass definition (EDIT: and consequently the Applicative and Functor definitions). If you don't understand what it means, learn about higher kinded types and typeclasses until you do. Once you understand what the definition means, that's it. No really, that's it. And now, since you're probably wondering what all the fuss is about, that's when you need to start learning by doing.
- white-flame 11y agoThere 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.
- kccqzy 11y agoMonads 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.
- imh 11y agoAt 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<B> bind(Maybe<A>, Function<A, Maybe<B>>) The Haskell notation says that it's a function that takes two arguments (separated by ->). The first argument (Maybe a) is either something of type a or Nothing. Nothing is like null. The second argument (a -> Maybe b) is a function of one argument that takes a thing of type a and returns either a thing of type b or Nothing. The Maybe monad defines this chaining function for you. It uses a function you provide to turn a Maybe a into a Maybe b. It's useful, because a popular alternative is to turn Maybe a into Maybe b by writing functions of type Maybe a -> Maybe b To write a function like that, you have to handle both cases, a normal value and a null value. This is a pain in the ass and I don't enjoy it. Wouldn't it be easier to only have to write a function that handles the non-null value? If the value is null, then it should always return null anyways! Why should I have to repeat that for each step of my code? Let's let the language detect our context (the fact that we're doing a bunch of Maybe operations) handle that for us. More generally, for monad m, >>= has type m a -> (a -> m b) -> m b You can make new monads if you define this function for it (and another function that's easier but I won't talk about). The reason it's worth doing is because it's easy to write code that handles simple values and returns complicated things (a -> m b), but hard to write code that takes complicated things and returns complicated things (m a -> m b). With monads, you write the complicated version once and then write simple code every time you use it. 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.
- kccqzy 11y agoI 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.
- cordite 11y agoI 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.
- Animats 11y agoWhat language is this? It looks like Javascript, but with some additional operators, such as "=>".
- deleted 11y ago[deleted]
- pklausler 11y agox >>= f = join (fmap f x) Contemplate until enlightened. But don't write YAMT afterwards.
- kika 11y agoI'd suggest a longer (1 hour) but much more correct explanation. It doesn't use math beyond high (or even may be middle) school. Video, unfortunately. https://youtu.be/ZhuHCtR3xq8 https://youtu.be/ZhuHCtR3xq8
- haskellsceptic 11y agoI see monad tutorial after monad tutorial posted here, but never some new, awesome piece of technology produced using Haskell. In fact, the only Haskell software I can think of is Darcs, a DVCS that was so buggy and slow when I first started learning Haskell in 2010 that the community recommended against using it, and of course xmonad, dons' tiling window manager that he flagrantly abused his moderator status on r/programming to aggressively promote. Yet Haskell remains one of the most popular languages here. There are more stories about it than Perl or C#. From this I can only conclude that Haskellers are all talk and no action, and IMO, this reflects very poorly on the language and its community. EDIT: Also, the downvotes that one swiftly and copiously collects from merely criticizing Haskell and its community also reflect very poorly on both.
- SSLy 11y agopandoc, quickcheck and git-annex are the first things that came to mind.
- haskellsceptic 11y agoJudging by the volume of posts here about it, there should be as impressive a portfolio for it as there is for C# or Perl. There isn't.
- tome 11y agoMathematics is also a popular topic on HN but there isn't an impressive portfolio of projects written in that either. Pretty daming for mathematics.