scripting language vs. developer community size

[linas@linas.org]

Hi Dan,

A view of the history and consideration of some practical matters may
shed some light.

Historically (about 3 years ago), the idea of scripting for gnucash was
discussed at length.  I personally was advocating perl,  not because
it was better, or that I liked it more, but because I knew there were 
zillions of perl hacks out there.  The gnucash reporting system was 
at that point a html-based cgi-bin-like thingy, and I felt that perl
was a natural for attracting all of that talent.

The talent that was attracted was a number of schemeres (well, mostly
one, Rob Browning, and various supporting voices).  And so with some
concern, hand-wringing, & etc. said 'ok, scheme too'.  There was already
a lot of perl code ('gnc-prices', and the reports in gnucash 1.2.x).
But in fact, no perl hacks ever did show up (excpet for Paul Fenwick, who
took the core of gnc-prices and turned it into the Finance::Quote perl
module on sourceforge).

I expected the perl/scheme code to be mostly 'superficial', with only
gadgets and do-dads using it. Instead, it become inside-out: scheme is now
at the core, and everything else is a do-dad that it coordinates.

There are several practical impediments to perl at this point:
--  Even if all the gnucash scheme coders died tommorrow, there's
    so much scheme code that it would be a massive undertaking to 
    re-write it.

-- Form time to time, interfaces do change, and it doubles the work
   if a set of maintainers have to support multiple API's in the face of
   change.  For perl to be practical in gnucash, we'd need a full-time 
   perl guy promising to keep the interfaces whipped into shape. 
   And we don't have that.

-- the inter-module problem: say, for example, gnucash wants to use
   the Finance::Quote perl module for stock quotes.  Then we need
   a way of having scheme call perl code ... debugging gets harder.
   Many bugs would require the scheme programmer to dive into perl code
   occasionally, or worse, the scheme-to-perl wrappers ...

   Meanwhile, the hot-shot perl rogrammer who has the whizband perl
   module, and wants to integrate it with gnucash... will need to 
   use scheme to accomplish that integration ... And so the needed
   IQ ratchets up a bit more anyway .... Sigh.  


Linas. 



It's been rumoured that Dan Kegel said:
> 
> Christopher Browne wrote:
> > Frankly, it's utterly unimportant if there are thousands of people out
> > there in "Internet-Land" that think Scheme is a ludicrous choice if, in
> > contrast, the core developers of GnuCash _all_ happen to like Scheme.
> > If the latter fact is true [and if not directly true, it's at least not
> > _vastly distant_ from the truth], then it's likely that Scheme will be
> > the Most Supported Scripting Language for GnuCash.
> 
> True.  However, if you find it hard to attract qualified developers
> to the project because only a few programmers are willing to learn 
> Scheme, GnuCash might develop more slowly than you like.
> 
> But hey, maybe you guys have plenty of people who regularly contribute code,
> and aren't hurting for programmers.  So, how many people *are* currently 
> contributing good Scheme code to GnuCash?
> - Dan
> 
> p.s. I hope to use GnuCash soon myself, and am quite happy that the
> latest RPM's install without trouble on Red Hat 6.2.  And 
> I'm trying to learn Scheme, so if I run into a feature I've
> gotta have, I can add it...
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
>