In my opinion, it is great that Scheme and Guile are on the way out.
I would suggest though, that something more than how few lines of code
are needed go into the determination of the language for the UI.
Otherwise, APL is going to win hands down. Even the presence of bindings
doesn't sway me much. The amount of UI code (and proper re-factoring of
business logic out of the UI) is probably going to be much larger than
the bindings. Part of me also cringes at the thought of using two
different languages for one application unless there is a good reason.
I'd argue for at least the following:
* Modern, object-oriented code
This one really goes without saying, I hope.
I'd personally prefer one that handles "multiple inheritance" in a
reasonable way and clearly supports anonymous functions, closures, and
"lazy build" functionality.
* Popular among developers
You want people to already have the skills to be able to contribute to
the project. The Open Source world is not really much different than the
commercial world. Now matter how slick "your" language is, it is going
to be much easier to, for example, find top-notch Java programmers, than
some niche language (unless it is deemed "the next great thing").
* "xPad" aware
Consider that I wouldn't be surprised if there are more iPads out there
than Linux desktops. Android is on the upswing. The increasing number of
handheld devices, to some extent, argues against heavyweight
interpreters. Why should the user have to not only download an app, but
also another language interpreter, and potentially another GUI
framework? I'm not saying that GNUCash must be in Objective C, but
thinking about platform support and impact is worthwhile.
* Understandability and Maintainability
I guess that rules out APL...
On 01/10/2011 02:24 AM, Christian Stimming wrote:
Dear all,
We've been discussing various future directions for gnucash, including
a switch to a different programming language for the GUI code [1]. GUI
coding in C sucks. Because of this, I've experimented with C++/Qt and
was able to write up a usable gnucash-like register window GUI in 2-3
weeks which already includes features that are unavailable in
"conventional gnucash" [2]. I chose C++/Qt because I'm very familiar
and productive with that platform.
However, a scripting language might be even more suitable for writing
the GUI code of a project like gnucash. The language Python is a
particularly good candidate here because gnucash already has python
wrappers for most of its underlying data type and storage code,
thankfully provided by Mike Evans and others. See
src/optional/python-bindings/ and the doxygen output [3] and the
example scripts in python-bindings/example_scripts/, in particular
scripts like simple_book.py: Loading an existing file, modifying some
of the data, and writing again, all in 12 lines.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
