Stephan Deibel wrote:
> Geoff Bache wrote:
>> "As a personal choice, we tend not to use debuggers beyond getting a
>> stack trace or the value of a variable or two. One reason is that it
>> is easy to get lost in details of complicated data structures and
>> control flow; we find stepping through a program less productive than
>> thinking harder and adding output statements and self-checking code
>> at critical places. Clicking over statements takes longer than
>> scanning the output of judiciously-placed displays. It takes less
>> time to decide where to put print statements than to single-step to
>> the critical section of code, even assuming we know where that is.
>> More important, debugging statements stay with the program; debugger
>> sessions are transient."
>> It takes even less time to figure out where to put a breakpoint
> _instead_ of a print statement and use the debugger to access the
> values you would have printed (or any that you might not have thought
> to print but turn out relevant). This is a big reason why Wing Pro
> has the Debug Probe. Another reason is you can immediately try out
> your proposed fix within the context of the problem. I find this
> approach is extremely effective in code I don't know well. It
> works even better in Wing 3.0 where you get auto-completion so you
> can easily guess at attribute/method names.
If effectiveness is measured only in terms of time to solve the problem
in hand
then I'm sure this is at least as effective as logging. The main
problem, though, is that it
is *transient* - the knowledge that you gain from stepping through the
debugger is
unavailable to other developers on your team, and will be unavailable to
you also
after a while if you don't constantly work on the same code. Logging, in
constrast,
builds up a knowledge base alongside the code which makes each debugging
session
slightly easier and faster.
With code I'm unfamiliar with I'd much rather read a log to get an
overview of what's
happening, than step through line-by-line until I know enough to be able
to set breakpoints.
> There is no silver bullet in software development. All of these
> things (and many I didn't mention) have their place and can be
> used together. I'd go so far as to say "Methodological purism
> found to be harmful" ;-).
I'm not arguing for methodological purism, just questioning some
development priorities.
Some people like debuggers and while that's true there's a market for
creating and improving them.
I just feel that the market for an effective Python code editor is that
much larger, and was therefore dismayed
that most of the effort seems to be being put into improving the
debugger while no major improvements
are listed for the editor in 3.0, despite obvious missing features that
are present in competing products.
Regards,
Geoff