Subj : Re: Not debugging?
To   : comp.programming,comp.lang.java.programmer,comp.lang.lisp
From : Jason Curl
Date : Wed Aug 24 2005 03:38 pm

Tim X wrote:
> rem642b@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> 
> 
>>>From: "Phlip" <phlip...@yahoo.com>
>>>The hirers are sick and tired of only getting kiddies who know .NET
>>>but don't know how to think to avoid debugging.
>>
>>I suppose it depends on what you consider "debugging". I write a line
>>of code and immediately apply it to the data I have to see if it gives
>>the data I want. If not, I change that line of code. If it works, I
>>move on to writing the next line of code. When I get to the end of the
>>function I'm working on, I put all those lines together and unit-test
>>the entire function on the data I was just using and any other cases
>>that are useful to make sure it really works correctly in all cases.
>>You consider that not to be debugging, correct? What do you call it then?
> 
> 
> I'm guessing he was referring to the irritating development of
> programmers who are not able to debug code without a high level IDE
> which includes a debugger which allows them to step/trace through the
> code one line at a time and watch what happens to variables in a watch
> window. 
> 
> IMO this is a really bad trend because it means programmers stop
> thinking about their code and how it actually works. this sort of
> 'debugging' tends to be extremely slow - especially for trivial type
> bugs which would noramlly be spotted very quickly by someone wh
> understands what their code is doing and how it works. 

Totally agree. The amount of time I save by "thinking" about my code 
(before I write it, and after I write it) is enormous. More often than 
not, my own testing doesn't find the problems that could occur, because 
it's difficult to get those test conditions. 1 hour of not doing any 
typing, just performing thought experiments and I've discovered very 
subtle problems with home-brew IPC protocols (via sockets).

Even better, when I am in a rush to release software to somebody, it 
works relatively well.

> 
> I cold be just from an 'old school' that pretty much predated
> integrated IDEs with all the snazzy features that are common these
> days. Debuggers were around, but often getting them and your code
> configured to use them, loadinig them up and setting breakpoints etc,
> was more effort than it was worth except for really difficult problems
> which could not be solved by looking at the code and thinking about
> what was going on at the logical level. 
> 

I find that not many people have thought about "unit testing" their new 
code. They'd prefer to write a new function that is reasonable (i.e. 3-5 
printed pages) and just compile it in with the already 100k line program 
and test if it works to find typos and stupid decisions that would have 
been caught if they'd unit tested it with another framework. They keep 
up the compile, fix cycle until it compiles the first time. No wonder it 
never works (and takes a day).

For me, it's emacs and the command line. I know exactly what's going on. 
And I read my code before I compile it to see that it makes some kind of 
sense.

On the other hand, debugging tools are extremely useful when interfaces 
that are external don't work (I've had this problem repeatedly with 
cygwin assuming a behaviour the same as Linux).

Jason.

.