Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Stop 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).



Well, that oft-maligned definition is actually what made it stick for me . . .


Right, 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)


>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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: