scripting language vs. developer community size

[Dan Kegel]

linas@linas.org wrote:
> A view of the history and consideration of some practical matters may
> shed some light.

It did, thanks. 

> --  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.

Yeah, interlanguage integration is a bear.

What's the consensus on http://www.gnu.org/software/kawa/ ?
According to http://www.gnu.org/software/kawa/kawa_11.html it provides
pretty good Scheme - Java integration.

It's vaguely tempting (assuming unlimited CPU power) to consider porting
the core of GnuCash to Java.  Then high-level development could be done
in either Java or Scheme or both; no special demands would be placed
on the IQ of the programmer wishing to call Scheme from Java or vice versa.

- Dan