I'm curious what sorts of things you have in mind when you refer to "pieces [of Haskell code] that require superhuman effort to type correctly"? In my own Haske

I'm curious what sorts of things you have in mind when you refer to "pieces [of Haskell code] that require superhuman effort to type correctly"? In my own Haskell experience, except when playing with silly and mostly pointless tricks like doing computations in the type system, I've never really felt like Haskell's type checking has been a hindrance. It's more like those inflatable bumpers on bowling lanes: it only stops me from doing the things that I wouldn't want to do anyway, like forgetting to check for failure conditions or allowing mutable state/side effects to seep into parts of my code that I intended to be pure. > However, it's often really painful to get that code to typecheck compared with the effort to get the same code correct in python or ruby. I'd argue that in the overwhelming majority of cases, the Python or Ruby code is equally incorrect to the equivalent Haskell code that doesn't type check, it's just that Python and Ruby don't tell you about it upfront, you find out about it at runtime. Hopefully, "runtime" means "during testing" and not after your code is in production. Or if you want to put a more positive spin on it, Python and Ruby let you run the code in spite of its lack of correctness. If that's the kind of freedom you want, then a dynamically typed language (or even a weak statically typed language) will suit you well. As for me, I've been burned by that "freedom" enough times now that I can't think of it as anything but a negative.