Hopefully Perl will one day attract such tools. (speaking of Visual Studio's debugger)

With all due respect, I sincerely hope not!

I routinely work in a state-of-the-art IDE with all the usual debugging bells and whistles, but strenuously avoid their use. Years ago, watching my collegues and myself bog down in "step-in", "step-out", "step-over" swamps, I began to suspect that such an approach to understanding a program is counterproductive. (And, as we all know, totally impossible for multithreaded code!)

Years ago Fred Brooks described the OS/360 linking loader as the most impressive, powerful implementation of a concept whose time had passed. I feel the same way about debuggers. With CPU clock speeds in the GHz range, and program execution times of minutes, hours, or months common (e.g. reactive systems, transaction processing, etc.), attempting to understand a program by single-stepping (whether at machine opcode or program statement) feels like trying to recognize a friend's face by examining DNA sequences.

I sincerely suggest that the sooner we get out of the habits of thinking about control flow and micromanagement (literally! ;-) and concentrate more on abstraction and composition, the better equipped we will be to write beautiful code that will effectively use those 80-core laptops soon to appear.

I earlier praised Mark Jason Dominius' book Higher Order Perl (and he in no way is to be held responsible for my ranting). That book provides an excellent introduction into thinking functionally rather than operationally. I can't speak highly enough of the value of making that shift in one's thinking, regardless of the language at hand.

Years ago, watching my collegues and myself bog down in "step-in", "step-out", "step-over" swamps, I began to suspect that such an approach to understanding a program is counterproductive.

I'll stop wanting it when there's another method to quickly track down bad/broken logic in someone else's spaghetti.

(Higher Order Perl) provides an excellent introduction into thinking functionally rather than operationally. I can't speak highly enough of the value of making that shift in one's thinking, regardless of the language at hand.

All that happens when one makes such a shift is that you tend to "operate" on type values, families of function, and protocols for abstraction (rather than a series of instructions for mutating state). These concepts are further from the grasp of most programmers today than the understanding they need of their own programs.

I'll be quite surprised if new programmers don't want state-of-the-art debuggers even after your revolution comes ;)

-David

If you're interested in this topic, you may wish to re-read the discussion starting at Are debuggers good?. I'm sure that the debate will never end. However I'm with Joel Neely, people who use more advanced programming techniques will tend to be the ones who choose not to use the debugger.