Re: gEDA-user: Flexibility and capability

[John Doty <jpd@xxxxxxxxx>]

On Oct 1, 2009, at 2:56 AM, Chris Smith wrote:

> John Doty wrote:
>> On Sep 30, 2009, at 2:29 AM, spuzzdawg wrote:
>>>
>>> This is the line of argument I really have an issue with. I mean
>>> making it easier to use by someone who doesn't want to command line
>>> everything.
>>
>> Does every tool have to be dumbed down to serve the computer-
>> illiterate? This is what really worries me. Finally, I have access to
>> a tool that makes it possible to actually use the power of the
>> computer to help a computer-literate part-timer like me be really
>> productive, and some people want to dumb it down to be like all the
>> other tools.
>
> We're not talking about dumbing down.  We're talking about adding a  
> few
> features to allow users to get results quickly, without having to  
> master
> the tools first.

That's not how it usually works. The scenario starts to drive the  
design, and the clean simplicity that made scripting productive  
disappears.

>
> As an obvious example, consider a digital SLR camera.  My camera  
> allows
> me to control every function to achieve the photo I want: shutter  
> speed,
> aperture, ISO, flash timings, etc.  To use those settings correctly I
> had to spend a lot of time reading about photography.  However, the
> camera also has an 'Auto' setting which, as a novice user, allowed  
> me to
> just press the button and get a good photo.  The addition of an 'Auto'
> function in no way detracts from the ability to use the camera  
> manually.

It's a lousy analogy. Look at real software examples. Say, netinfo,  
where NeXT starts by putting a GUI atop the classic "flatfile" Unix  
admin data, but then the GUI starts to drive the show. Soon, you have  
data in the database that doesn't conform to the flatfile paradigm,  
and you are then restricted to administering your systems in the  
tedious and non-portable way that netinfo's designers imagined you'd  
prefer.

>
>> Scriptable data flow means that a simple "make" can rebuild all
>> project data products, without requiring that the designer remember
>> the details of a flow from years ago. At the same time, one can adapt
>> the flow to the project's needs, not some narrow channel the tool
>> requires. The Makefile formally documents many of the details of the
>> project's structure and flow (of course informal comments are also
>> helpful, and the Makefile is a good place to collect them, too).
>>
>> Simple, transparent file formats mean that "textutils" processing of
>> files is easy and very effective. It only took me a few minutes to
>> write my pins2gsch script, but it has already saved me many hours of
>> work.
>
> That really is the issue, isn't it?  All the talk about gEDA's clean
> interfaces really boils down to the fact that it uses an open file
> format that other tools and scripts can easily interpret.

Not just files. While *drawing* naturally requires user graphic input  
to work smoothly, other operations don't. The gEDA tools are very  
good about not demanding graphic input when it's not needed. Even  
gschem can be used in scripts, and gnetlist is a marvel of flexibility.

>
> You seem afraid that integration means that gEDA and PCB will become
> fused into a single entity, and that the schematic file format will
> become corrupted, or disappear entirely.  I see nothing that justifies
> that fear.

History justifies that fear. It's difficult to find any example of a  
toolkit that evolved into an integrated tool and maintained its  
flexibility and productivity.

The glib assurances by the core developers justify that fear. If I  
saw a recognition of just how hard what you describe is to pull off,  
I'd be less worried.

The lack of appreciation for gEDA's strengths that I see here  
justifies that fear. Taking them for granted is a sure way to lose them.

And "integration" is just one symptom of a deeper problem. gEDA is  
amazingly flexible. It is not tied to a narrow development scenario  
the way other tools I've used are. But the desire for "integration"  
comes from a specific scenario. If we let one scenario drive the  
design, flexibility will inevitably be lost.

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