"Bradley M. Kuhn" <[EMAIL PROTECTED]> writes:
> I am Guile fan as well, but I think it's important to allow Perl to
> do as much for folks as what Guile can do. Is there any way to keep
> this behavior, or does your design forbid it?
>
> If it's the former, and you just lack the time to maintain, I may have found
> how I might finally do some coding for this project. :)
Well, I really think we're headed for madness if we take the approach
that all interpreters need to be first-class citizens. IMO that's
just too much complexity to maintain. Imagine we have guile embedded,
and then we add perl because someone wants it, then someone else
thinks we should have python embedded, and then someone else wants
Tcl/Tk. Now we have four separate interpreters, all loaded up and
running everytime you launch GnuCash, each one with it's own
(potentially incompatible) memory management schemes, threading
schemes, signal handling schemes, and IO schemes.
Even if those issues weren't too serious, we'd still have an
integration and linking nightmare, not to mention probably serious
size/memory bloat, and more importantly, as soon as anyone starts
using one of these languages for an important function, it would no
longer be an optional add-on, it would be required. This means that
everyone would have to have it installed properly to build and run
GnuCash, and I think you can make a convincing case that GnuCash is
already hard enough to build.
So, after thinking about all these bits, we decided that we needed to
pick just one language as the embedded one. In the end we went with
Guile. To be fair, that's probably in large part my fault. I did a
lot of the work with both the perl and guile stuff, and I pushed in
the guile direction once I had played with both, but no one else
seemed to mind too much.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
