[OT] Which IDE / Editor do you use?

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Sep 14 01:40:30 PDT 2013


On Sat, Sep 14, 2013 at 03:28:14AM -0400, Nick Sabalausky wrote:
[...]
> I love writeln debugging. I don't have to boot it up, configure it,
> learn about or task-switch my mind over to any new interface, or
> actively shy away from any opportunities that don't come with a
> fully-mature debugger (or wind up with my arms tied when I'm in the
> debugger habit and don't have a debugger available for whatever
> reason - in my experience, debuggers are reliance-forming drugs).
> 
> But the *best* thing of all with writeln debugging: Being able to
> examine the entire relevant execution forwards *and* backwards in time,
> all at a glance, with zero "stepping". Total win.
> 
> Any time I use a debugger I get sooo sick of having to reset and hit
> "step" a million times (or muck around with conditional breakpoints,
> which never seem to be intuitive - *if* they even work at all) every
> single time I want to see (or remember) what happened *before*. But
> with writeln - I already see the whole relevant trace at a glance, and
> all with exactly the same tools and interfaces I'm already using.
> 
> Writeln debugging rocks my world.
[...]

Hmm. Now that you put it *that* way... maybe I should stick with writeln
debugging after all. :-P  You're right that the most annoying thing
about having a "real" debugger is the fact that you can't step
backwards. The only thing is, you have to recompile your program each
time... but with D's compilation speed, it actually becomes a real
alternative. Hmm.

One use case that has no writeln equivalent is stepping through assembly
code when something REALLY screwed up, like when dealing with dmd
codegen bugs. Though for that case, I did recently adopt the method of
reading disassembly code listings. I've actually located and fixed
several bugs in my work project this way (not with dmd, I mean, but with
a C program). People will of course object that assembly is "too obscure
to learn", "too hard", ad nauseaum, but I agree with what Knuth said
once: if you don't know how the machine *actually* works, the programs
you write will be pretty weird (i.e., far removed from reality). IMO the
ability to read and understand assembly should be a requirement for
every professing programmer.


T

-- 
If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.


More information about the Digitalmars-d mailing list