Mail Archives: geda-user/2015/02/07/12:47:18
On Sat, Feb 07, 2015 at 08:17:42AM -0700, John Doty wrote:
>
> On Feb 7, 2015, at 7:06 AM, John Griessen <john AT ecosensory DOT com> 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"
- Raw text -