Has anyone ever encountered a Monad Transformer in the wild?
In my area of business - back office IT for a financial institution - it is very common for a software component to carry a global configuration around, to log its progress, to have some kind of error handling / computation short circuit... Things that can be modelled nicely by Reader-, Writer-, Maybe-monads and the like in Haskell and composed together with monad transformers.
But there seem to some drawbacks: The concept behind monad transformers is quite tricky and hard to understand, monad transformers lead to very complex type signatures, and they inflict some performance penalty.
So I'm wondering: Are monad transformers best practice when dealing with those common tasks mentioned above?
Answer
The Haskell community is split on this issue.
John Hughes reports that he finds it easier to teach monad transformers than to teach monads, and that his students do better with a "transformers first" approach.
The GHC developers generally avoid monad transformers, preferring to roll up their own monads which integrate all the features they need. (I was told just today in no uncertain terms that GHC will not use a monad transformer I defined three days ago.)
To me, monad transformers are a lot like point-free programming (i.e., programming without named variables), which makes sense; after all, they are exactly programming point-free at the type level. I've never like point-free programming because it's useful to be able to introduce the occasional name.
What I observe in practice is
The number of monad transformers available on Hackage is very great, and most of them are pretty simple. This is a classic instance of the problem where it's harder to learn a large library than to roll your own instances.
Monads like Writer, State, and Environment are so simple that I don't see much benefit to monad transformers.
Where monad transformers shine is in modularity and reuse. This property is beautifully demonstrated by Liang, Hudak, and Jones in their landmark paper "Monad Transformers and Modular Interpreters".
Are monad transformers best practice when dealing with those common tasks mentioned above?
I would say not. Where monad transformers are best practice is where you have a product line of related abstractions which you can create by composing and reusing monad transformers in different ways. In a case like this you probably develop a number of monad transformers that are important for your problem domain (like the one that was rejected for GHC) and you (a) compose them in multiple ways; (b) achieve a significant amount of reuse for most transformers; (c) are encapsulating something nontrivial in each monad transformer.
My monad transformer which was rejected for GHC did not meet any of the criteria (a)/(b)/(c) above.