IDEs Of Change

WHERE IS THE IMPROVEMENT?
Cheaper. Faster. And smarter? Integration has been a major improvement in IDEs. Likewise, incremental improvements in compiler tool chains have enhanced program size and efficiency, though these features tend to be relatively transparent in day-to-day IDE use.

So far, most IDE-specific enhancements involve editing, sourcecode manipulation, and screen management. Features like color coding are the norm. This goes for templates, keyword completion, and popup help for variable and function definitions.

Refactoring has become a more important feature, due to the increasing size and complexity of applications. Even simple renaming changes can break an application. Having the IDE handle this chore cuts down on potential problems, and it could reduce the number of induced bugs.

Another important aspect of IDE concerns screen management, thanks to larger monitors, multiple screens, and more powerful PCs that can switch quickly between a number of applications. The ability to see more information lets developers choose more quickly and examine more of the system, whether during editing or while debugging. Likewise, developers are having to track more information, such as the status of network makes or support for team or pair programming.

Additional screen real estate is always welcome during debugging. This is especially true for multiple task applications and multiple core debugging. More windows means more information about each task and each core.

Some systems like VisualDSP++ can add to the clutter with useful graphs that often tell more than a whole screen of numbers (Fig. 3). Unfortunately, many of these kinds of insightful features tend to be very vendor-specific.

Still, debugging seems to remain one area with limited IDE improvements. Craig Haller, president of Macraigor Systems, says that most developers tend to use the same debugging techniques from 30 years ago, from silly things like print statements to very basic use of breakpoints.

Many debuggers offer much more complex tools, but they're often unique to a particular IDE or are difficult to use. Often, they aren't used because the developer doesn't know about them. Or, the tool may be hard to use.

Tracing is a good example of an underutilized tool. Tracing was quite common in the past. The high cost of external in-circuit emulator (ICE) systems slowed its use, but it has enjoyed a resurgence as more chips incorporate trace support within the chip. Unfortunately, using trace information for debugging is even more of an art than using a regular debugger.

Tools like Green Hills Time Machine improved the situation with slick interfaces and easy-to-use analysis tools (Fig. 4). Green Hills is one of the few companies that's also managed to feed back the results of tracing to the compiler and linker for improved optimization. Inconsistent implementations of tracing support within an IDE seem to be the biggest obstacle to general use.

Some improvements to debugging have been coming from outside the IDEs. Virtutech's Simics system simulator shows how developers can gain access to more system information versus a conventional debugger, because the processor core itself is simulated. This can be very handy when targeting multicore environments. Here, the ability to stop or synchronize the system is easy with the simulator but often difficult in hardware.

Graphical programming IDEs like National Instruments' LabView hold an edge in presenting system status in a more revealing way. Most IDEs don't offer the ability to click on an object and set up a display of its status, which is updated while the application is running or when a breakpoint occurs—especially when the information is displayed in a graphical format.

Picking the right IDE remains a task with many options, even as the total number of unique platforms becomes smaller.