From: Eric Hodel <drbrain@...7.net>
Date: 2006-07-07T09:02:10+09:00
Subject: Re: debugging proposal

On Jul 6, 2006, at 6:10 AM, Lothar Scholz wrote:

> Hello Austin,
>>>> 1. refactor
>>>> 2. unit test
>>>> 3. write to stdout / stderr / log files
>>> I haven't done too much real work on ruby yet, but I still believe
>>> this is a very bad suggestion.  Ruby (and any programming  
>>> language) is
>>> about productivity and in my whole experience (I have to agree that
>>> most of it is spent on Java) never a sout have been more productive
>>> than a debugging session (for enough complex stuff).
>
> AZ> I think you misunderstood. This isn't a suggestion. It's just  
> how one
> AZ> ends up debugging most of the time. Frankly, I think I have  
> missed a
> AZ> graphical debugger exactly once in my Ruby programming. Everything
> AZ> else has been easier to deal with with judicious use of tracers  
> and
> AZ> logging.
>
> Well, i and many of my customers will not agree with you.
> I have to do this print/logging debugging with eiffel
> many times (even with DbC) and i see minutes and minutes passing by.
> (There is no useable debugger for SmartEiffel).
>
> And also a debugger is the only wonderfull tool that helps you to
> see and oberve the control flow, together with the data. No tracer can
> do this. In complex and not very well documented frameworks like rails
> this can save you hours. It took me minutes to understand REXML and
> not hours of trail/error until you now what types/objects are expected
> and returned by each function.
>
> Unforunately productivity is something that is hard to measure and
> even harder if you are convinced that your own style is already good
> enough. There was only one try to deal with this. The so called
> "Personal Software Process" but too less people are using it because
> it requires additional time and a _LOT_ of diszipline (no wonder that
> this was developed from somebody who was a drill sergeant during his
> army time).

The times that I need a debugger for my ruby code match exactly to  
the times my ruby code is far too complicated, poorly factored, or  
poorly tested.

Here's what debugging usually entails when I partake of it:

1) Code breaks
2) mess around to find the breakage via the debugger
3) Fix
4) Goto 1

Sometimes step 2 will be the same every time because my fix wasn't  
right, but sometimes it will be slightly different.  Having to  
repeatedly type the same (or similar) things into the debugger is  
really, really annoying.

Unless step 2 is automatic, unit testing will beat out using a  
debugger.  (And when it is automatic don't you have a test case  
anyways?)  With test cases I can be reasonably assured I'll find a  
problem before I need to think about using the debugger.  With just a  
debugger I get neither automatic protection nor repeatability.

-- 
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com