Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")

[John Doty <jpd@xxxxxxxxx>]

On May 6, 2010, at 5:45 PM, Windell H. Oskay wrote:

> 
>> A community database would need trillions of symbols when the combinatoric
>> possibilities are considered. Now how big is the community that's
>> contributing? There are 41 contributors to gedasymbols. They have
>> contributed 1392 symbols. That's a measure of the capacity of this
>> community. Now, I'm not disparaging that effort, and indeed I will
>> continue to contribute to it and exploit it. How about you? But I have no
>> illusions that this will solve the whining about symbols, even if we could
>> enlist every EE in the entire world to contribute.
> 
> Nobody but you is claiming that we need trillions of symbols nor all the
> EEs in the world.  Straw man much?)

Nobody else has really thought about the magnitude of the problem. I challenge you to make a list.

> 
> Instead, please consider: If it becomes easier to produce and use useful
> symbols, the number of users and the number of people likely to contribute
> useful symbols could grow very, very quickly. Telling people over and over
> again that they're idiots for wanting something like that will does just
> the opposite. It lead to a lower rate of symbol creation.

I encourage people to contribute to gedasymbols. Where is your contribution?

> 
> 
> 
>> And that's exactly what we have. But having a set of symbols for every
>> likely use is impossible. Ditto for a "database" that represents their
>> attributes (it's really the same thing, just packaged differently).
> 
> Again, you're arguing against a position that nobody is arguing for.

Not true. If the database behind the GUI tool is inadequate, the GUI gets in the way. Users will have to get used to reaching around it anyway. That will drive away everyone who thinks it should actually work, while the few remaining will drop back to the workable flow, and the cute GUI feature will have only driven people away.

This problem is already present in the component selection dialog in gschem. A *true* advance in gEDA would be to have this lead the user directly into the necessary customization, instead of promoting the illusion that this step isn't necessary.

> 
>  Nobody needs to build a filled database from scratch, nor does the
> database structure need to be perfect on the first version.

Ah, but it does have to be perfect. Otherwise there will be lots of whining about what a piece of crap gEDA is. People won't be able to find their favorite component. People will design boards, fabricate them, and be shocked when pin numbers turn out to be wrong.

>  Having
> *capacity* to introduce symbols and attributes for every likely use--

You have no comprehension of how far "every likely use" goes. gEDA isn't just a toy for hobbyists.

> for 90% of people who are using gschem and/or PCB to build circuitry--is
> quite likely.
> 
> And, it will grow the community, which will lead to increased availability
> of ready-made starter symbols.  It will never be perfect or 100%
> inclusive, but that's hardly a reason to give up.

Sure. Contribute your symbols to gedasymbols. I encourage this. But the delusion that this can somehow lead to a situation where a user can just pick a component from a menu without both careful checking and customization is damaging.

>   For every corner case
> (plumbing, thermal simulations, VLSI, and who knows what) there's still
> scripting capacity.
> 
> 
>>> Your insults don't change the fact that something that adds great value
>>> to
>>> 90% of users without removing functionality is a net gain.
>> 
>> But something that leads them down a dead end path is a loss.
> 
> Your continued abusive behavior towards n00bz and veterans alike here is a
> damaging, dead end path that leads to loss for all of us.  EDA is
> irrelevant to the problem.

Huh? EDA is what gEDA does!

> 
> 
>> You misrepresent my position.
> 
> In which way?  You seemed to agree with the position that a blank canvas
> is better than the Mona Lisa.  Have you changed your mind?

It depends on what you need. The Mona Lisa is a finished piece, not a tool at all. But a supply of blank canvas is part of a toolkit that can produce a variety of paintings.

> 
> 
>> I've contributed several gnetlist back ends
>> to the project. And there are a couple of useful scripts in my gedasymbols
>> area. But these actually work, and solve the problems I intended to solve
>> with them.
> 
> I acknowledge and appreciate your role as contributor to the project.
> I even saw that you were nice to someone on the list last week. (I was so
> surprised that I saved the message for future reference.)  However your
> contributions do not compensate for nor justify your actions on this
> list.
> 
> Perhaps you should also consider acknowledging and appreciating that
> people here discussing gEDA are also trying their best to contribute to
> the project.

To contribute you must first appreciate gEDA's strengths. Are you saying that every bad idea somebody has should go into gEDA?

> 
> 
>> Cute features leading to dead ends (although unfortunately very
>> common in modern software) are not an advance.
> 
> Deciding in advance that every possible feature is a "dead end" or is just
> "cute" isn't helpful.

I don't.

>  Shooting them down without discussion necessarily
> prevents advances.

Bad ideas are not advances. Discussion includes pointing out that ideas are bad. Most ideas for "improving" a well designed software toolkit like gEDA will be bad. Even bug fixes can be bad if poorly designed: every poorly designed fix makes the next fix harder.

>  I think that it's a very accurate description of your
> position to say that you're opposed to advances in gEDA.

I am not opposed to advances in gEDA. Obviously. I've contributed some. I am opposed to added complexity that cannot lead anywhere useful. I am opposed to the lack of even semi-quantitative thinking by those who believe that more symbols or some sort of database can turn component selection into point-and-click. I am opposed to adding special-purpose "features" to flexible tools.

> Can you really
> argue against that conclusion?
> 
> I for one-- and I am not alone --have grave reservations about discussing
> gEDA features on this list.  It's bound to be a dead-end path so long as
> you keep this up.

"Features" are not an intrinsic good.

I suggest you read:

gaul.org/files/program_design_in_the_unix_environment.ps

In particular, learn the lesson that adding features to a clean, simple program is a bad idea.

In software, "features" belong on the "cost" side of the cost-benefit ledger. The hardest thing about modern software is the fog of unnecessary "features" obscuring what's actually going on. "Capabilities" go on the benefit side. So a feature that leads to no new capability is a bad thing. Even a feature that adds a capability is bad if it damages the factoring of the toolkit (see the paper referenced above). gEDA has an unusually low level of fog, an unusually high level of capability, and is unusually well factored (Hurray for gEDA! Well done, Ales!). I would wish you could appreciate this, and adopt the Hippocratic principle: first, do no harm.

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