Well, I mean, I do expect people reading a monad tutorial to have existing programming background, that goes without saying. I will say that I think imperative programmers are better equipped to understand them than functional programmers actually, since we're the ones writing all the boilerplate in the first place. Think of your Link.js library and the problem it solves 
Programmer-to-programmer: the thing is, the monad concept itself is not actually complicated, people just make it seem that way - sure, individual monad types are complex (promises, e.g.), but the monad interface is ridiculously simple:
// entangle/unit/pure/return
let arr = Array.of(1, 2, 3);
let m = new Maybe("foo");
let prom = Promise.resolve(812);
// map
arr = arr.map(x => x * 2); // we know what this does
m = m.map(s => s + "bar"); // maybe it has a value, maybe not - it's a no-op if not
prom = prom.then(value => newValue); // just map to new value, no async shenanigans
// flatmap/chain/bind/thru
prom.then(result => new Promise(...)); // promise chaining
m.thru(value => new Maybe(result)); /* alternatively, Maybe.Empty */); // maybe it can fail
arr.flatMap(elem => Array.of(...)); // one-to-many mapping
That's it. If you implement that interface and satisfy the identity laws, it's a monad. Literally. That's all that's required. It doesn't matter what kind of abstraction it's an interface *to* (promises, arrays, maybes, eaty pigs...), you just need to implement the interface. The main thing is that the pattern this interface represents already exists in "nature"--you have to train yourself to recognize it though, and that's the actual hard part.
Topic: So I wrote a monad tutorial... (Read 168355 times)
previous topic - next topic
Community for the Sphere game engine