🚀 go-pugleaf

In article <4fjnch$oqq@solutions.solon.com>, tangent@cyberport.com (Warren Young) writes:
|> 
|> Anyway, a relevant quote from the article: "One question I often ask a
|> programmer is, 'How good are you at using the debugger?'  If they're
|> an expert at using the debugger, then I know they're not a very good
|> programmer.  There are things where you have to be expert at using the
|> debugger, such as writing operating systems or device drivers, and
|> those are different cases.  But in general, if you are writing
|> application-level code, then you shouldn't have to use a debugger.  It
|> implies you weren't being very thorough in writing the program in the
|> first place."
|> 
|> I think this is a pretty accurate assessment.  I disagree with his
|> opinion that application programmers shouldn't (ever?) have to use a
|> debugger, but I do agree with his general opinion of expert debugger
|> drivers.
|> 
|> [Fascinating! -mod]
|> 
|> = Warren --

I find this fascinating too.  (As alert readers may have suspected ... :)
I'm usually well acquainted with the system debugger.  But, subjectively,
this is not because I chase down many bugs with it, but because I
like to check my programs interactively---seeing if the arithmetic is correct,
checking loop invariants, checking pointer assignment/dynamic memory allocation,
and so on. During the first few iterations of the edit/compile/test cycle,
I will single-step through the code and check every line, thus finding exactly
where the program starts veering off course.

I like to think of debuggers as interactive program validation environments.
I used to look at my code a lot before testing it---this is not to say
that I don't think about my code a lot before and while writing it---but the
misconceptions and oversights that are the source of many bugs don't get
caught that way.  In the debugger, I have the actual values of all variables
at my fingertips.  I think this way is faster & more flexible.

It is definetely faster and less error prone than adding printf statements
all over your code.  The people I know who don't use debuggers have simply
never taken the time to learn one.

The trend definitely seems to be going toward more powerful debuggers---see
gdb.  In fact, the CSRC at Bell Labs has created a *debugging language*
called ACID that you have to program to get it to do anything...
even single-step!  The advantage is that you can get it
to check complicated assertions---debugging in the large, if you will.
Of course, the debuggers they had
before that, adb and its plan9 variant, weren't symbolic and kind of
primitive, and this
seemed to me the way they wanted it to be.  (``ed is the standard
text editor,'' and all that).

Konrad Schwarz