Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!violet.berkeley.edu!csm
From: csm@violet.berkeley.edu
Newsgroups: comp.cog-eng
Subject: Re: Debug techniques. What's your favorite?
Summary: The nicer the debugger the longer the debugging
Keywords: debugging, abstraction, levels of description
Message-ID: <22878@agate.BERKELEY.EDU>
Date: 10 Apr 89 21:17:36 GMT
References: <1499@wasatch.UUCP> <877@syma.sussex.ac.uk>
Sender: usenet@agate.BERKELEY.EDU
Organization: University of California, Berkeley
Lines: 27

There are certain classes of bugs for which fancy debuggers
are terrific.  In C the best example is a segmentation violation.
All you have to do is start up the debugger and there you are,
positioned at the exact offending statement.

However, more other sorts of  bugs, like omitting an '=' to yield
	if ( x = y ) /* Assignment */
instead of
	if ( x == y ) /* Test for equality */
are not found quite so quickly.

I have no data, but I would suspect that given a corpus of
differing bugs, debugging time is directly proportional
to the skill of the programmer with only slight gains to be had
from sophistication of tools.

The most important element of the debugging tool is probably the
amount of time it takes from hypothesis to rerun.

The most important skill is learning how to develop the hypothesis.
(Unless tenacity is considered a skill.)

I have seen programmers (particularly novices) hypnotized by 
single stepping through a program.  Fancy debuggers are 
therfore extraordinarily useful as a pedagogical tool!

	Brad Sherman (bks@ALFA.Berkeley.Edu)