[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: gEDA just hit SlashDotOrg



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/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user