I realize my precursory understanding on Monads is severely lacking in detail considering my knowledge comes mostly from Douglas Crockford's Monads and Gonads talk and complicated with my sevear handicap with Haskell (which looks like a bunch of non-alpha numeric characters mushed between disjointed English words to my tragically disadvantaged brain).
With that being said, I'd like to ask about programming practices concerning Monads and how they could be implemented in JavaScript. I'm prefacing this because I recognize that the very nature of the language can drastically affect how one perceives a concept and that because of my background in JavaScript this question could be inappropriate if it were based in a purely functional language like Haskell.
Often times while designing an interface or coding an object I will find myself implementing a form of chaining which mutates the encapsulated data. I prefer this style over more declarative forms like passing in a multi-lined object literal.
function Declarative(options) {
this.options = options;
}
Declarative.prototype.compute = function() { ... }
var x = new Declarative({
foo: 'foo',
bar: 'bar'
});
x.compute();
Verses:
function Chained() { }
Chained.prototype.withFoo = function(v) {
this.foo = v;
return this;
};
Chained.prototype.withBar = function(v) {
this.bar = v;
return this;
};
Chained.prototype.compute = function() { ... }
var x = new Chained()
.withFoo('foo')
.withBar('bar')
.compute();
Both these examples (aesthetics aside) raise a few hairs on my back because a small voice mockingly squeals "Mutability much?" I begin thinking this might be a good time to conciser a Monad pattern. What I mean by that is each method would in short return a new object of the same type. Then adding composition functions on it like map, bind, etc. could off a world of potential like I get with Promises and other Monad type. (Obviously taking care to follow the three Monadic laws when implemented).
Finally, my other half of the brain starts chiming in with "If all you have is a hammer, everything looks like a nail." Sigh. That is when my productivity and creativity crash here on SE curious and confused.
While I continue my research for understanding (perhaps gaining enough courage to contemplate Haskell) I ask: When does the idea of Monads (that being composability of functions on objects (ie types) along with immutability) become a good idea to be cultivated and patterned? And, when is it nothing more then an over utilized hammer?
(Concepts and learning opportunities welcomed, example code helpful)
Maybe
(failure),(->) a
(functions/global environment), or[]
(lists/nondeterminism). Even if Haskell was impure (something that would, IMHO, "cripple" it even more), I think it would still be more expressive with monads than without.)IO
doesn't actually do anything unless you return it from main.putStr "Hello"
does nothing.main = putStr "Hello"
does something. 2) That quote is a fallacy, because pure functional programming is still a relatively new field. You've also missed his point, which is that characterizing functional programming as taking away mutation misses the point - the point of FP is improved modularity.