ummm, I think citing and expounding on the philosophical differences of
one approach (integrated) versus another (multiple tool kits) is a nice
amorphous description and somewhat akin to mental masturbation. The
philosophy of gEDA has already been established. What is more
important is that the tool suite *flawlessly* supports a small subset
of generally accepted design-fabrication paradigms, eg workflow from
schematic to completed & populated board, and a subset of potential
offshoot efforts such as circuit simulation, head modeling,symbol
creation and package creation and management, etc.
My premise is that if you put 100 design engineers in a room who have
done circuit design to board fab and ask them to produce a scenario of
their work flow, at least 40% of them would have a common scenario.
So the important questions to ask and answer are:
Do you know what the top 2 (or 3) scenarios are?
Do you know what the top 2 (or 3) parallel offshoot activities are?
How well can those scenarios by fulfilled by the tool chain
approach?(Conceptually)
How well can those scenarios by fulfilled by the tool chain approach,
in reality (e.g do the tools work flawlessly and do they scale?)
If someone buys into a certain philosophy and the tool implementation
causes them pain, they will search for less painless approaches and
adapting ones development scenario is much easier than trying to
understand and patching someone bogus code.
Another point is don't stick ones head in the sand and start slinging
code so that the additions 'do something'....Consider 'the other
religion' and the possibility that one might want to import a schematic
developed in kicad, Altrum, orcad or whatever because PCB is the
sexiest thing on earth. One also needs to consider outflow of a design
from gEDA to whatever.
Make a road map, have a plan, follow the plan and have at it.
J
On Wed, Aug 24, 2011 at 1:03 PM, John Doty <[1]j...@noqsi.com> wrote:
On Aug 24, 2011, at 8:33 AM, Jared Casper wrote:
> I chuckled at what this community would think of the comment, in
> response to "There are users who prefer separate dedicated
> applications to an integrated design environment.", "BTW. How many of
> these users have ever designed a PCB with more than 4 layers and,
say,
> 300 components? From my own experience, above the certain level of
PCB
> complexity the intuitiveness and efficiency of the GUI become a
> paramount. "
I think that's exactly backwards. The "intuitiveness and efficiency"
of the GUI make for comfort, but not productivity. In a big design,
the key is to break it down into modules, and then use the
automation to put the modules together. This is especially true when
you recognize that a big design encompasses not just EDA, but
documentation, software, and possibly other things. The toolkit
approach allows you to combine these things in a maximally automated
flow.
I've seen the difference starkly in software. I personally don't
care what tools a programmer uses as long as they get the job done:
this should be a matter of individual preference. Except, it is my
experience that programmers who prefer toolkits are much more
productive than programmers who prefer IDE. They plan better, they
factor better, and they exploit the power of the computer better.
One serious problem is that IDE encourages very inefficient
debugging practices: it's much better to trap bugs with assertions,
logs, and analysis than to fish for bugs interactively.
Yes, it takes more thought and planning to use a toolkit. For simple
jobs, a nice intuitive GUI is fine (I'm typing this to the Mac
"Mail" app). But planning is more important for big jobs, and a
toolkit rewards planning better. Spending time to adapt your
processes to the job is a big time saver for big jobs.
A flexible, extensible, toolkit is especially superior for jobs that
have characteristics that fall outside the limits of the application
designers' imaginations. Try exporting KiCad designs to a computer
algebra system for symbolic analysis (but the Mathematica back end
for gnetlist only took me an afternoon to write).
The important thing to recognize is that there is room for, and a
need for, both toolkits and integrated tools. AWK and spreadsheets
are both effective at processing tabular data in their own ways, but
a merged tool with the characteristics of both would be
incomprehensible. I think the same is true in EDA.
It is my opinion that gEDA's developers and users should embrace its
strengths as a powerful, flexible toolkit. Keep the tools separate.
Keep the interfaces clean and simple. Maximize the rewards that
those who can do a little scripting can earn. Let KiCad cover the
integrated app space.
It would be useful to be able to import KiCad schematics, so that
when users are ready for the more powerful toolkit we could offer
them an upgrade path.
John Doty Noqsi Aerospace, Ltd.
[2]http://www.noqsi.com/
[3]j...@noqsi.com
_______________________________________________
geda-user mailing list
[4]geda-user@moria.seul.org
[5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
References
1. mailto:j...@noqsi.com
2. http://www.noqsi.com/
3. mailto:j...@noqsi.com
4. mailto:geda-user@moria.seul.org
5. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
