[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