Joe English writes:

Sengan Baring-Gould wrote:

...

http://www.catb.org/~esr/writings/taoup/html/ch01s06.html

...

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

On Mon, 24 Feb 2003, Malcolm Wallace wrote:

Joe English writes:

...

Me either; in fact even 1/4 of the time debugging sounds quite high.

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.

But surely "fighting the typechecker" is exactly a debugging activity. The great benefits are that you remove the bugs before even running the code, and you are finding specification errors in addition to mere implementation errors.

[standard caveat: I write research code for image processing problems, which may well be very different to, e.g., code implementing a COM wrapper.] Mentally I classify bugs into two kinds: `source code bugs' and `algorithm bugs'. Source code bugs are when the program you write isn't doing the same thing as your mental model of your algorithm, algorithm bugs are when your code is performing the same as your mental algorithm. You can't really argue that `algorithm bugs' aren't bugs because (i) it's easy to have a specification which is precise without being either obviously acheivable and having no obvious algorithm for performing it; sometimes the only way to make progress on the program is to try and iteratively develop an algorithm/implementation to solve it. (ii) more importantly, when something doesn't work you don't get a clear indicator of which kind of bug it is, and you often have to engage in `traditional debugging' to finally see that the code is doing what you think it is and that your errors are due to an algorithm bug. If you discard `compliation preventing, very very quick to solve' bugs (e.g., missing semi-colons in C++, silly typecheck errors in Haskell) I find that the ratio between source code bugs and algorithm bugs is maybe 1:5. This means that whilst I find Haskell a great deal easier to write correctly than C++, there's not that much difference between debugging times for Haskell and C++ because the algorithm level bugs dominate. (In fact, it's in some ways easier to do algorithm debugging in C++ because it's very easy to temporarily stash things in global variables so you can have it available for `debugging processing' in parts of the program where it isn't available under the normal argument passing. Of course you then have to clean the mess up...) And I'd certainly say 3/4 time spent debugging is probably an underestimate for me (given the def of debugging above). ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:tweed@cs.bris.ac.uk | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh

On Mon, 24 Feb 2003, Andrew Moran wrote:

Dave Tweed wrote:

...

If you discard `compliation preventing, very very quick to solve' bugs (e.g., missing semi-colons in C++, silly typecheck errors in Haskell) I find that the ratio between source code bugs and algorithm bugs is maybe 1:5. This means that whilst I find Haskell a great deal easier to write correctly than C++, there's not that much difference between debugging times for Haskell and C++ because the algorithm level bugs dominate.

In my experience, the number of algorithm bugs is usually about the same, regardless of which language you're using. And simple source code bugs are no real problem in any language.

I think I was a bit unclear: I agree that no of algorithm bugs is essentially independent of programming language. What I was trying to say was that whilst there's much less debugging time on `non-trivial' source code bugs (by which I mean things like, say, having a nested if which doesn't work the way you think it does) is much less in Haskell, those are a relatively small proportion of the bugs. Consequently there's not a big disparity between the time I spend debugging Haskell and time spent debugging C++ because language independent bugs are the bottleneck. So in my case I couldn't justify using Haskell on the grounds of reduced debugging time. (I could justify it on lots of other grounds of course...) ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:tweed@cs.bris.ac.uk | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh