The characterization of FP-style approaches to the problem makes me question that it is a canonical example at all; rather I would regard it as a strawman of FP

The characterization of FP-style approaches to the problem makes me question that it is a canonical example at all; rather I would regard it as a strawman of FP style, or otherwise not idiomatic or awkwardly designed. If Haskell is indeed unergonomic for the purpose of supplying multiple different logger implementations, it would seem that it would also be unergonomic for the purpose of supplying multiple different exception/error handling implementations. But... it's not? See `catchE` [0] from Control.Monad.Trans.Except: catchE :: Monad m => ExceptT e m a -> (e -> ExceptT e' m a) -> ExceptT e' m a ... where the callsite-provided exception handler is the second parameter to the function, which can do basically anything (especially if the monad m is MonadIO). Hardly unergonomic or overcomplicated in my view, and no effects algebras or even type declarations in sight. There is already a canonical example and it is the "Expression Problem," [1], where in FP "you optimize for extensibility of the number of operations in your model, at the cost of reduced developer ergonomics when attempting to extend the number of types you can operate upon. In the latter, object-oriented approach, you have the inverse tradeoff." [2] [0] https://hackage.haskell.org/package/transformers-0.6.1.2/docs/Control-Monad-Trans-Except.html#v:catchE https://hackage.haskell.org/package/transformers-0.6.1.2/doc... [1] https://wiki.c2.com/?ExpressionProblem https://wiki.c2.com/?ExpressionProblem [2] https://news.ycombinator.com/item?id=41450851 https://news.ycombinator.com/item?id=41450851