Re: gEDA-user: Foss-pcb Proposed plan from CERN

[John Hudak <jjhudak@xxxxxxxxx>]

   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]jpd@xxxxxxxxx> 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]jpd@xxxxxxxxx

   _______________________________________________
   geda-user mailing list
   [4]geda-user@xxxxxxxxxxxxxx
   [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

References

   1. mailto:jpd@xxxxxxxxx
   2. http://www.noqsi.com/
   3. mailto:jpd@xxxxxxxxx
   4. mailto:geda-user@xxxxxxxxxxxxxx
   5. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user