Path: utzoo!attcan!uunet!iconsys!ohs!bhil
From: bhil@ohs.UUCP (Brian T. Hill)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Mini-flame: Debugging Techniques
Message-ID: <530@ohs.UUCP>
Date: 10 Apr 90 18:46:50 GMT
References: <19428@boulder.Colorado.EDU>
Organization: Orem High School, Orem, Utah
Lines: 32

From article <19428@boulder.Colorado.EDU>, by pratt@boulder.Colorado.EDU (Jonathan Pratt):
> In article <11051@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> 
> [Complains about people posting problems without working hard enough
> on them first.]
> 

[Reminder that even the best miss an obvious problem now and then.]

> that people post their programming woes.  A few words from an expert
> probably saves them hours and hours, and they only have to endure a
> few insults to get the advice.
> 

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.

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.  It's incredible how often "perfect" code
doesn't work.  I've seen it before: code that is theoretically flawless
that does everything wrong.

Brian T. Hill   bhil@ohs.uucp  ohs!bhil@uunet.uu.net