You've piqued my interest around the state monad specifically, and I just added a long but promising-looking article on it[1] to my reading queue. However:
> Sometimes the "monad patterns" will appear in a language under another name, or will be used "under the hood" to implement a particular API. Clojure/Script's `let` for example is essentially the Identity Monad; and its `for` is very much akin to the List Monad (the same is true for list comprehensions in other languages).
I knew this from reading monad tutorials. And yes, certainly there exist useful things that happen to be monads. But I question the usefulness of explicitly pointing that out and saying, "Here's a monad library. I'm going to use this monad library to build X. You can use all the normal monadic functions on X, because it's a monad", as opposed to putting the monad stuff to the side and just building X. What would you gain from building `let` or list comprehensions atop a monad library? Would it be worth the users you'd confuse? The concept of monad is far too abstract to be intuitive to most people, so there is a cognitive cost to making people think about them.
Jim Duey's blog post on the State Monad was helpful to me[1].
I agree that one shouldn't reach for monads just because one finds them interesting or neat, or challenging for that matter.
An analogy: consider that in many cases, `while` and `for` loops are great when looping is what's called for. But there are many times when recursion is more attractive still. But what to do if your language doesn't have TCO, and blowing the callstack is a real concern? Well, then you can use trampolines![2]
Now, trampolines are great, but you don't need to always reach for them. An analysis should be done of the problem at hand, and "the right tool chosen for the task", which may be a simple `while` loop. The same goes for monads. Are there cases where the State Monad makes the most sense among other programming patterns? Yes, I think so. Particularly, when you are trying to model a multi-step and nested-steps computation where the steps are intertwined in such a way that one can easily identify "global state" at work. In that case, the State Monad is a tool that will let you thread the global state through the steps and levels of computation without having to twist yourself into knots doing it some other way AND without relying on unfettered mutability.
> Sometimes the "monad patterns" will appear in a language under another name, or will be used "under the hood" to implement a particular API. Clojure/Script's `let` for example is essentially the Identity Monad; and its `for` is very much akin to the List Monad (the same is true for list comprehensions in other languages).
I knew this from reading monad tutorials. And yes, certainly there exist useful things that happen to be monads. But I question the usefulness of explicitly pointing that out and saying, "Here's a monad library. I'm going to use this monad library to build X. You can use all the normal monadic functions on X, because it's a monad", as opposed to putting the monad stuff to the side and just building X. What would you gain from building `let` or list comprehensions atop a monad library? Would it be worth the users you'd confuse? The concept of monad is far too abstract to be intuitive to most people, so there is a cognitive cost to making people think about them.
1. http://brandon.si/code/the-state-monad-a-tutorial-for-the-co...