Perhaps his "argument" doesn't make sense because it isn't an argument, it's a list of examples. Of course, insinuating that you don't trust the comment because the author points to his own libraries is a golden example of an ad-hominem fallacy, but in order for such fallacies to be relevant, this would have to be a debate, and it isn't, it's just you aimlessly complaining.
If you wanted to make it into a meaningful debate, perhaps you could furnish us with a non-Haskell example of:
- A differentiation library that avoids the perturbation problem at compilation time,
- A library for defining compositional uniform access across structured data types,
- A dependency injection framework with an algebraic basis,
- A speculative evaluation library that can safely discard running processes,
- A name binding library free of ordering effects
While I'm quite sure with some searching you could find one or two of these, most of them depend on the strong safety guarantee provided by Haskell isolating side-effectful processing in the I/O monad. Other languages can do this (or have other ways to do this) but none are popular enough to have such a wealth of libraries as to have these problems already solved. Unless, you know, I'm factually off-base. I look forward to seeing what you have to show us.
That's the first time I noticed that mtl was a DI library. Transformer classes are just such a nice concept in and of themselves that I never found value in mapping the concept back to something like DI. I'm definitely using that going forward.
