This comment has a lot of facts wrong. > Even if a library works, debugging edge cases is never thought of. Many libraries use sum types to express their api

This comment has a lot of facts wrong. > Even if a library works, debugging edge cases is never thought of. Many libraries use sum types to express their api which naturally leads one to consider edge cases. > Almost nothing is written about testing in Haskell. Yes there is! Did you verify your claim with a quick search? Here's what one gave me: - https://mmhaskell.com/testing/test-driven-development https://mmhaskell.com/testing/test-driven-development - https://jaspervdj.be/posts/2015-03-13-practical-testing-in-haskell.html https://jaspervdj.be/posts/2015-03-13-practical-testing-in-h... Heck, here's one from 2007: https://www.jasani.org/posts/2007/unit-testing-with-hunit-in-haskell/ https://www.jasani.org/posts/2007/unit-testing-with-hunit-in... It feels like this web of lies about Haskeller's not caring about real world concerns is being spun, but even with minimal effort that is trivial to disprove. > No two libraries can agree on which monad stack to use, The mtl library is the most used monad stack by far and it's not typical to see others very often. > so a non-trivial amount of integration code involves matching and lifting into other monads (nor the performance implications of doing all of this matching and lifting). I feel this may betray a lack of understanding because lifting between monad stacks is expected. I agree there are performance implications on theory, but if you get out of the performance ivory tower you'll find it doesn't happen much in the real world ;)