I started programming in Basic on a teletype machine with a paper-tape punch. Then I "graduated" to punch cards and Fortran. All the while, I generated heaps of paper. A faster printer was often the key to higher productivity. Eventually, I used glass teletypes and even built my own from scratch. Writing programs using EMACS on a terminal at 300 baud was an improvement, and it significantly cut back on the amount of paper I used.
Everything changed with interactive debugging. PRINT statements still cluttered the code, but those little breakpoints were amazing. This discovery had more to do with a switch from Basic to assembler and C than finding a better development environment. Breakpoints, memory dumps, and register displays led to source-level debugging. That, in turn, led to watch windows and expandable structures. Eventually, graphical-user-interface-based debuggers made the mouse indispensible.
These advances appeared incrementally as processor performance and program size increased. Many of the additions were necessary as more-complex programming languages and environments like C++ and Java showed up.
It may sound like debugging has made vast improvements over the years, but that's not true. Debugging tends to be the stepchild of development tools, and many of its advances have either fallen by the wayside or else remained hidden from the masses of developers. In fact, debugging tends to be the least-understood aspect of development, which is surprising because debugging takes up a significant percentage of development time, regardless of the quality of the design or the designer.
Early on in my development path, I had the advantage of using two languages that made me become very critical of development and debugging tools: Lisp and Smalltalk. Their interactive environment still rates as one of the best, and many favorite interface features of popular development environments came from them. For example, debugging extensions through macros or modification of the development user interface still aren't possible with most of today's development tools.
Few debugging tools allow third-party additions. Microsoft's development platform moves in this direction, but add-ons are still rare. Open-source debugging tools come the closest to allowing enhancements. Frequently, though, they require wholesale understanding of debugging and corresponding modification of the debugger source code for any major enhancement.
I think that embedded developers should de-mand more flexible and expandable debugging environments. Unlike many application developers who rarely deal with a debugger, except for difficult bugs, embedded developers find a good debugging environment critical. Customization of the debugging environment can pay dividends each time the debugger is employed.
For instance, it's often handy to have a dialog box that provides a display of the critical details inside an application or the operating system. Sometimes this can be accomplished using watch windows. But setting this up each time most debuggers run is tedious. Putting this support inside the application is nothing more than a glorified PRINT statement. Designers need a way to define a window via the debugger that displays this information so that the application itself is only modified while it's run under the debugger.
Do you have a favorite tool or add-on that provides great diagnostics for a debugger? Let me know. We might see some improvement in the debugger arena.