In my experience writing code in Haskell, you spend about 95% of your time debugging type errors and 5% of your time debugging actual bugs. The good thing about the former is that it's effectively the compiler finding the bugs for you.
Haskell is the only language I've used (obviously, not the only one in existence) where I am not surprised when a large program works correctly on the first successful compilation.
Disclaimer: Haskell is not my main language, I'm mainly a C programmer.
jbooth, if you try Haskell out you'll be very surprised. It's often true - it's just that it takes a lot more work to get a Haskell program to compile.
You're right - I should have been more critical of the comment, rather than making it personal.
I agree with the sentiment that often, "once it compiles, it's correct", but people don't stress what Matt Might does enough: "In fact, experienced programmers become adept at encoding correctness constraints directly into the Haskell type system." If you just write Haskell (OCaml, etc.) like you would Python, it's not going to make much difference - it's all about representing higher-level assumptions at the type level, and many people new to H-M languages don't know how to do that effectively.
* String processing (if you want to tell me how a type system prevents string processing bugs, I'd love to hear it)
There's no such thing as a magic bullet, and the claim is way overstated. It might be less prone to bugs than loosely typed systems, that's something I'd have no problem believing. I'm a fan of strong typing myself.
Haven't done any Haskell coding, but I just seriously doubt that in any language.