>>4
I think types are not required for handling side effects well. Not for the programmer, because they can easily be documented (naming conventions etc), and not for implementations, because it isn't hard to infer (at least conservatively).
The information gained from the types is often incomplete and sometimes even misleading. Rather than using them to gain information, said information should just be passed (in the case of Quickcheck random generators). This might look like more work, but I think it's not that much compared to creating
accurate types, and it's certainly simpler.
(I don't know much about Quickchecking monadic functions so I can't comment on that)
>>7
Writing imperative Haskell isn't that painful, but because it is not 'imperative by default', adding a single impure feature later to pure code (say logging some debugging values somewhere) means you have to restructure a lot of things. For instance if
f is changed from pure to impure, then
map f l must be changed to
mapM f l and
h $ g $ f x to
f x >>= liftM (h . g) (I think), of course propagating upwards. Ideally they could just stay the same, which is exactly what imperative by default achieves. Maybe 'composable monad by default' will do this too, but then what's the difference?
I mostly write pure code, but when I write a bit of impure code I don't want to be hindered by the language, especially when I don't see the advantage in doing so.