Path: utzoo!attcan!uunet!unisoft!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Mini-flame: Debugging Techniques
Message-ID: <11100@hoptoad.uucp>
Date: 13 Apr 90 15:15:15 GMT
References: <19428@boulder.Colorado.EDU> <530@ohs.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 62

In article <530@ohs.UUCP> bhil@ohs.UUCP (Brian T. Hill) writes:
>Those few words are indeed precious, but more precious sometimes is the
>knowledge gained from finding one's own solution.  Many times I've put
>the debugger to the test.  Often these sessions are long and tedious,
>but I've learned much from them.  Sometimes, the debugger doesn't help
>and I resort to older techniques of writing things to the screen at
>critical moments during program execution.  Little by little, I track
>down the source of my problem and fix it.  Certainly I could ask the
>experts, who would have known right away what I had done wrong, but I
>wouldn't have learned as much about the problem and other problems alike.

Very true!  The flip side is that by answering other's questions,
frequently one's research teaches one a great number of things which
one (or two, for schizoids, or more for cluster minds) wouldn't have
known otherwise.  Unfortunately, answering questions which people could
have solved for themselves with an hour in the debugger rarely is
useful in this way.  It is the student's duty to facilitate the
teacher's learning, as well as the more widely known vice-versa.

>An expert is a great thing, but they don't just happen; they come from 
>long hours in the debugger, I'm sure.  I agree with Tim Maroney:  Before
>coming here for help, give the problem some thought.  More than that,
>though, give it some work.

Yep.  And if you have done some work, be sure to tell us some relevant
information so we'll know that you did sit with the debugger first.
Try to give it straight, not filtered; remember, you may be drawing
wrong conclusions from the debugger information if you can't solve your
problem.  It doesn't do any good to jump to the conclusion that (as a
purely hypothetical example) the window list doesn't always terminate
in a null if, in fact, the window list *does* always terminate in a
null and you've just misread things; tell us what you saw.

>It's incredible how often "perfect" code
>doesn't work.  I've seen it before: code that is theoretically flawless
>that does everything wrong.

Truer words were never spoken.  This is why you simply can't program
seriously without using a debugger as a matter of course.  Looking at
source code is just not enough.

And one more thing -- if someone *does* give you the answer, why not
thank them in e-mail?  Most people are pretty good about this, but a
few will just take your answer and use it without feeling any of the
normal human social obligations of gratitude.  This is annoying, and it
makes it less likely that the answerer will bother in the future.

(Incidentally, I recommend ignoring Pratt's mean-spirited and
irrelevant rehashing of an old mistake of mine, a rehashing which had
nothing to do with debugger techniques.  Everyone here makes mistakes,
even Larry and Keith.  Pratt seems to have some personal vendetta
against me, and I'm sorry that he keeps unleashing it here.)
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"In science it often happens that scientists say, 'You know that's a
 really good argument; my position is mistaken,' and then they actually
 change their minds and you never hear that old view from them again.
 They really do it.  It doesn't happen as often as it should, because
 scientists are human and change is sometimes painful.  But it happens
 every day.  I cannot recall the last time something like that happened
 in politics or religion." -- Carl Sagan, 1987 CSICOP keynote address