Monads Explained Quickly
breck-mckye.com
Monads Explained Quickly
1–10 of 42 posts
Re: Monads Explained Quickly
#2"Monads Explained Quickly, But Mostly Incorrectly" would be a better name.
Isn't what's defined here mostly just a functor?
Re: Monads Explained Quickly
#3This article is almost entirely wrong
Re: Monads Explained Quickly
#4"Monads Explained Quickly, But Mostly Incorrectly" would be a better name. Isn't what's defined here mostly just a functor?
Half 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".
Re: Monads Explained Quickly
#5"Monads Explained Quickly, But Mostly Incorrectly" would be a better name. Isn't what's defined here mostly just a functor?
Half 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]
Re: Monads Explained Quickly
#6Wouldn'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;
}Re: Monads Explained Quickly
#7Some things are easier to learn by doing. These exercises (https://mightybyte.github.io/monad-challenges/) are what made it stick for me.
Re: Monads Explained Quickly
#8Stop 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).
Re: Monads Explained Quickly
#9Stop 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 (Promis…
Well, that oft-maligned definition is actually what made it stick for me . . .
Re: Monads Explained Quickly
#10Stop 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 (Promis…
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)