Interested in what the general sentiment is on this...

One of the great things about Flex, and CS3, is the "real" debugging; the ability to set breakpoints, step into/over code, and actually inspect variables and objects while the app is running in debug mode.

Recently, I've been working with Red5 a lot (great fun btw, if you haven't worked with it yet you really should pull it down). The way Red5 has you set up projects, you wind up using Log4j a lot, which is ok by me, since Log4j is very useful (Log4j is a logging library useful for capturing all kinds of info, traces and errors in running Java code).

In these travels, I came by some references to the book, "The Practice of Programming", and in particular, this bit from the authors:

"As 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;
debugging sessions are transient."

While I believe the above is not entirely true (debugging sessions can indeed be persistent, debug profiles, dumps, etc...a breakpoint is persistent), I do find that, with rare exception, I almost never run my code in full-on debug mode to find out what's wrong with it.

This probably has a lot to do with the way I write my code; if you write as long procedural switches in single classes with hundreds of line of code, you may have different debug needs, but I work really hard to make my classes really tight and to the point, so when something goes wrong, I can usually figure out where to look just by seeing what went wrong, dump a few traces and/or log4j infos, and solve the problem.

The reason I find this interesting is, a few years ago when I was doing a lot of .Net development, I swore up and down by the VS.Net debugging tools (which are great). So, when Flex Builder dropped, I was glad to see it. But as I've evolved as a coder and my overall knowledge of AS/Java/etc. has deepened, I find that the reasons I was glad aren't really something I particularly care about anymore.

This also makes me wonder; by having the crutch of these integrated debugging tools, do you right looser code, because, as long as you can step through it in your debugger and nothing goes wrong...why think harder about factoring it carefully?

As I mentioned, true and not true...for example, I'd hate to debug lots of async threads with traces, I like to see the threads in some kind of running display. But that's a particular kind of development that isn't really relevant in the world of ActionScript.

Interesting...

ActionScript is a [ "funny" ] thing.