Re: gEDA-user: gEDA just hit SlashDotOrg

[John Doty <jpd@xxxxxxxxx>]

On Aug 12, 2009, at 12:01 PM, Dave N6NZ wrote:
>
> Come on, people, aim higher.  The EDA world has learned and re- 
> learned a
> lot of lessons in the past 30 years.  Why isn't gEDA interested in
> leading the way?  Why is gEDA only interested in re-inventing 1980's
> suckage?  Where is the desire for excellence?
>
> As to gEDA being a "power tool".... oh, puuullleeeze.  gEDA won't  
> scale
> to anything meaningful.

The fellow looking over my shoulder just said "You're living proof to  
the contrary". ;-)

>   In the 1980's I was a mainframe CPU designer --
> think 30-40 engineers plus 30-40 techs all trying to get the  
> schematics
> correct.  gEDA would be a nightmare in that kind of a project.  I  
> can't
> imagine using gEDA on anything bigger than a 40 sheet or so, one  
> person
> project.

Certainly the scaling that gEDA currently excels at is cutting  
projects that would normally require a team down to a size that one  
part-timer can tackle. You can't understand how *extremely* grateful  
I am for this.

>   And even then, gschem needs a good off-page signal
> cross-referencer.  (Cue the fan-boi: "Just write a script!" Ha ha...
> come back when you grow up.  That needs to be built in and just work.)

This gets a bit tricky in a reuse situation where the same schematic  
is used in several contexts. An efficient gEDA flow has a lot in  
common with a software development flow. And software folks know some  
things about cutting big jobs down to size that most hardware folks  
don't. I haven't heard anybody complain that you have to run a  
separate tool like Doxygen to get a call graph in a typical software  
development situation.

>
> Anyway, 80 engg+tech projects are long behind us.  I've seen CPU  
> design
> projects with 350+ engineers and 10's of thousands of sheets of
> schematics.  When gEDA can scale to that, it will be a power tool.
> Until then, drop your delusions of grandeur.  It's getting in the  
> way of
> your seeing the scalability and usability problems in geda.

What I don't want to see is a *need* for a 350+ team. And in my  
field, when you see a big team it's certain that this is dictated by  
*institutional* needs, not by the real needs of the job.

>
> gschem is a toy-scale tool for toy-scale projects.

I like to achieve large scale goals with toy-scale means. The HETE-2  
ground comms network came in at 1% of the cost NASA formulas  
predicted...

>   It has 1980's era
> interfaces, functionality, and problems.  Most of these problems are
> well known.  Many are even well solved in other tools.

I don't consider extremely expensive, complex tools that cater to the  
needs of institutions to create inefficient divisions of labor to be  
a good model.

> Please, set your sights higher,

Set your sights higher. Don't feed the trend to overspecialization  
and low productivity.

> fast-forward 2 or 3 decades, go see what
> the other guys do, and try to produce a tool that actually *is*  
> excellent.


We have different metrics for excellence. There is room for that. But  
again, I'm extremely grateful for a tool that bucks the trend here.  
On one very large project I'm working on (partly in gEDA), I'm told  
I'm the only contractor who is on schedule. Now if they'd just get  
the contract situation straightened out so I can get paid (grumble)...

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