X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on fly.srk.fer.hr X-Spam-Level: X-Spam-Status: No, score=-1.0 required=6.3 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 Date: Sat, 7 Feb 2015 18:46:57 +0100 From: Ivan Stankovic To: geda-user AT delorie DOT com Subject: Re: [geda-user] gschem, gnetlist, libgeda, pcb code architecture (was: FOSDEM) Message-ID: <20150207174657.GA2538@alpha2> References: <90236728-E79D-47C7-BFB1-34140DB85ACB AT sbcglobal DOT net> <201502042333 DOT t14NX28o024789 AT envy DOT delorie DOT com> <7C1A5871-3056-482C-BC58-173D90D80F77 AT icloud DOT com> <54D61BDF.402!0504 AT ecosensory DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: GNU/Linux User-Agent: Mutt/1.5.23 (2014-03-12) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t17Hk37f006690 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, Feb 07, 2015 at 08:17:42AM -0700, John Doty wrote: > > On Feb 7, 2015, at 7:06 AM, John Griessen wrote: > > > Ease of adding improvements is top importance for volunteer projects. > > Yes! It’s not just that gEDA is a volunteer project. The jewel of gEDA > is all those gnetlist back ends. I completely agree with that. > Scheme is accessible enough to allow > some great contributions here, even though much of the contributed > code is not very clean. Many of these were (successfully!) > “cargo-culted” from other crude examples by engineers with minimal > Scheme knowledge. It helps that the gnetlist API trivially presents > the coder with the data needed to construct a flat netlist or BOM, so > the job is largely a matter of organization and output formatting. > Unfortunately, the deeper layers of information are inaccessible, so, > for example, hierarchical netlisting requires external scripting. > That’s not so nice either, because configuration info (at least in > released versions) is only easy to get at in Scheme. Scheme has not > been as successful at extending gschem. Indeed. I've once written a pygtk-based component browser for Farnell, that let me connect to their site, search for components, retrieve data such as price, availability, datasheets etc. My intention was to make it very easy to make the light -> heavy transition for my symbols, by automatically adding attributes generated from the Farnell database. It actually looked nice (even had a component preview!), until I came to a point where I needed to plug into gschem. After some messing around I just gave up, because the result was not pretty, implementation-wise. One might wonder why I chose Python + gtk, instead of using gtk bindings for guile. Well, after spending some time configuring and trying to get a working build of guile-gnome, I simply switched to Python and gtk because the infrastructure there is way easier to start with and definitely more tested over the years. > But I think that Python is hands-down the most successful teaching > language ever. In addition, it’s tremendously successful application > language, with modules for just about every application domain > (http://xkcd.com/353/). I think it’s important that your extension > language be capable of connecting to other domains. All those modules > make that easy. Again, I have to agree. In fact, in my day job we were at some point (~7 years ago) considering using guile very seriously as a platform for our next family of software products in the domain of automotive simulation. We even had a framework prototype written in scheme, and at some point custom gtk bindings were written. In the end, it was decided that Python was a better option, and so far it's been serving us nicely. With a big product release last year and at least two more coming this year, I think one can safely say that Python had a major role in the success. Note I'm talking about hundreds of thousands of lines of code that needs to couple to dozens of libraries, some written in C, C++ or FORTRAN (which is still much used in these fields). For us, the ability to easily integrate to many different libraries was very important. And here Python helped also in another sense: often a functionality that was in a separate C library came with the Python's standard library. Also, I remember that there was an argument in favor of Python that went something like this: "This is Scheme. Who would want to use it outside our team? Imagine the macro insanity out there if we go with it." Though funny, I do think this quote represents a more pragmatical approach to choosing the right tool for the job. When you have dozens and dozens of programmers, of various backgrounds and various competence level, you don't want to force them to use Scheme or any other language that you know they will have problems with. Whether the same reasoning is applicable to free software EDA, and gEDA in particular, I can't really tell. But a good first starting point would be to look at the facts, such as the number of currently active developers, developer activity, the rate of attracting new contributors etc. In the end, it's not about the tool or about the programming language. It's about the community, because the community does the job, not the tool or the language. So, I'd say the question really becomes "how do we establish and maintain an active, healthy developer community?". -- Ivan Stankovic, pokemon AT fly DOT srk DOT fer DOT hr "Protect your digital freedom and privacy, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm"