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 ;)
> 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://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...
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 ;)