Re: gEDA-user: Yet another netlister

[r <nbs.public@xxxxxxxxx>]

On Sat, Aug 1, 2009 at 2:37 PM, John Doty<jpd@xxxxxxxxx> wrote:
>
> Hmm, I think Guile is fine for gnetlist's purposes. A minor problem
> has been backward compatibility, leading to "dependency hell". The
> people who package the distros have this under better control than
> they did a few years ago. Python has similar problems.

I'm actually a big fan of functional languages so you don't need to
convince _me_ to Scheme. ;-)

> The real problem, I think, is that many people get phobic when they
> see all those parentheses. But, really, Guile is easy to learn and
> easy to use.

Well, I see several other problems here as well:
1. Guile (as a Scheme implementation) is not particularly well
supported, this leads to "dependency hell" and missing/incomplete
wrappers for modern libraries (like gtk2 - not really a problem for
gnetlist but an issue for gschem and others),
2. Scheme being a simplistic language. Both Perl and Python come with
regexps and easy to use and versatile container types to name a couple
of useful features.
3. Scheme not being a main stream language (often misinterpreted as a
"parentheses problem"). This makes code written in Scheme not easier
to extend than one written in a primitive but well known language.

So, from pragmatic POV, I am OK with moving from Guile to something
more practical.

>> and gnetlist architecture is
>> hardcoded in C,
>
> Yes. Too much is hardcoded into the front end. The front end even
> gets in the way of the back end's access to command line options.
> Back ends can't see hierarchy. Back ends can't see all attributes.
> Now, a lot of back ends don't need to see all that stuff, but that's
> what the interface layer (gnetlist[-post].scm) is for: simple back
> ends can get the filtered info, trickier ones can reach around to the
> front end and get the data they need. The current implementation
> doesn't exploit the capabilities of the interface layer very well.
> The front end needs to be trimmed back to the minimum, and the logic
> moved to the interface layer.
>
> Hmm. In the gnetlist case, the minimum for the hard-coded part is
> nothing: why bother with C at all?

Fully agree.

The only exception is that part of functionality (reading and
interpreting gEDA file formats) could be abstracted out in a form of
libgeda library (still the netlister doesn't need to be written in
C/C++, just libgeda itself).

Regards,
-r.


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