In other words, if static types alone are giving confidence to refactor, it is a false confidence except in the most trivial of cases.
In other words, if static types alone are giving confidence to refactor, it is a false confidence except in the most trivial of cases.
As a consequence, a lot of peoples primary experience with type systems is limited to "this should return a list of strings", which like you said, is one small class of problems (though I'd argue it's huge win compared to not having that guarantee).
Every project needs tests, but like all things, what happens in practice is seldom ideal and thus the more you can offset to (reliable) automated tools the better.
Simple, vanilla Haskell is approximated more and more by the mainstream languages: Optional types, andThen().orElse() and friends and other things - which I am really happy about!
Why not use a more mainstream langauge then? For me, there are at least 3 hard reasons:
1) The stuff mentioned above is old, battle-tested and deeply embedded into the language and the community - it feels ergonomic to use.
2) IO-being-a-library is a paradigm that produces programs that I love to maintain, also when others written them.
3) Haskell has nice interfaces that I miss in mainstream languages, Functor and Monad for example. My prediction is that in around 5 years, mainstream languages will start to offer these kind of interfaces - starting from "Wait, what else can we do with andThen() and optional chaining and so on?"