[wingide-users] Word completion and refactoring support

[Geoff Bache]

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