["D. Tweed"
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...)
Well, I'd like to point out two subtleties in this argument... First, it's important to remember that source-level bugs tend to recur each time substantial source changes are made (in some languages, they tend to recurd with just about the same frequency). So, even though source code bugs are the smaller percentage of bugs you have to fix, minimizing the recurring cost of fixing them can be a big improvement. Second, this ties in with overall reductions in cost-of-change that (arguably) come with high-level languages: sure, there may be as many algorithm bugs in your Haskell code as in your C/C++ code, but your program is much more maintainable and robust to change, so the cost of correcting/exploring those bugs is much lower. I'm sure you are well aware of all this, but I just wanted to point out that it's definitely more complex than a simple 1:5 source code to algorithm bug ratio (or whatever...). Matt -- Matt Hellige matt@immute.net http://matt.immute.net