[EMAIL PROTECTED] 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
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
