On Aug 2, 2009, at 5:20 PM, Bill Gatliff wrote: > One of the ways that the gdb guys cracked this nut was to push a > lot of > their functionality into libraries, and create an HID-centric API for > them. They include a command-line-interface implementation by > default, > but then others can take those same libraries and build their own GUIs > around them. And drag in libraries from other places to add > functionality that gdb doesn't itself provide. So now Eclipse, DDD, > Insight, and many other frontends can all use the same gdb backend > rather than inventing their own. Everybody wins.
For one of my space missions, we had a company write much of the software. They were really big on IDE's with interactive debugging. But there was part of the system that was buried in a way that made it inaccessible to the interactive debugger. They complained bitterly about this, but there was no practical alternative. But when it came to do the work, the guy who had to suffer without the interactive debugger was consistently ahead of schedule, and produced software that was nearly bug free. The other programmers were chronically behind, and their software was infested with serious bugs. I visited their shop, and what I saw was disturbing: programmers stepping through buggy code hour after hour. But the guy who couldn't do that had a much higher productivity flow: unit tests, defensive coding, etc. took more thought up front, but they saved time in the end. The term "fritterware" comes to mind. Fritterware is easy to get started with, comfortable, addictive, and ineffective at doing the job (although not ineffective enough that its users notice). It sells well, and its users believe its bad characteristics to be essential. Interactive debuggers like gdb are fritterware. In ordinary environments, gdb's only genuinely useful command is "bt". In embedded environments there are a few more. But all the massive complexity of stepping, breakpoints, etc. is pure fritter, suppressing thought and wasting time. Putting a GUI atop something that's already fritterware is harmless. Putting a GUI atop a graphical application is a good thing. Putting a GUI atop a complex, poorly factored (or intrinsically unfactorable) tool can help the user navigate the mess. But one should strive for an effective, cleanly factored toolkit that doesn't need a GUI except where real time interaction with the user is unavoidable. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
