Joe English
Sengan Baring-Gould wrote:
states that "debugging often occupies three-quarters or more of development time". I don't think that is my experience in Haskell... more like 1/4 at most. I was wondering what others felt.
Me either; in fact even 1/4 of the time debugging sounds quite high.
I think it depends a lot on various factors, and that more important than language is project size, programmer experience, and effort spent in the design phase. For a small, one-programmer project, debugging is IMHO much simpler than in a multi-programmer, multi-year project, in particular an ill-designed one. I think this is a fairly accepted fact in the field of software engineering.
When I first started using Haskell, most of my time went to fighting with the typechecker, but once the code checked it almost always Just Worked. This is a pleasant experience.
I can relate to that. On the other hand, finding the really obscure bugs is (at least to me) *hard*. The bugs would probably be hard regardless of language, except perhaps lazyness-related bugs (if you can call that kind of undesirable behaviour a bug).
Nowadays, I spend the most time trying to understand the problem, relying on the typechecker to tell me when I've misunderstood something.
I think the type syntax itself, just not the checking tools, help. E.g. reading Paul Graham's "A Plan for Spam", I note that in order to segregate strings from headers and body, he rather awkwardly prepended header strings with the originating header -- e.g. "Subject: foo" were stored as "Subject*foo". Much nicer to do data Token = Header String | Body String deriving ... -kzm -- If I haven't seen further, it is by standing in the footprints of giants