Is there anything *enjoyable* about our development process?

Stuart D. Gathman stuart at bmsi.com
Fri Oct 14 15:39:56 EDT 2005


On Fri, 14 Oct 2005, Josh Sled wrote:

> On Fri, 2005-10-14 at 13:53 -0400, Chris Shoemaker wrote:

> - get rid of scheme, it's dependencies and the startup loop.

There needs to be some kind of embedded script language.  Both
to provide a high level interface to the underlying C code, and so
that the high level code is immune to bugs like buffer overflows and
dangling pointers.  I did not like the choice of Scheme, but only because of
personal preference (I hate the syntax).  It has been on my TODO list to get up
to speed on it for some time in order to hack on Gnucash.

	No Perl Please!

If anyone is thinking of changing the preferred script language,
*please* *please* don't make it Perl.  It looks like chicken scratches.
When I have to hack non-trivial Perl code, I first translate it to Python.
It's faster that way.

	Python and Ruby

Python (LISP semantics, modern syntax), or Ruby (Smalltalk semantics,
modern syntax) would be good choices.  Both are included in most
distros by default.  Note that VIM follows the model of a C core
with two script languages (vim macros and Python) tacked on.  It actually
works very well.  Since the python interpreter is a shared lib, already
loaded by various system processes, startup for a Vim python script
is instantaneous.

Python code can run in native threads created by a C library.  The
interpreter can "attach" itself to an existing posix thread.
Last I checked, Ruby could only run in threads that it creates.

	What about Java?

The standard Java runtime is a stuffed turkey.  However, the language
itself is fine.  I run Java 1.1 JVMs in 256K of ram to do encrypted
tunnel proxies and other embedded style applications.  The Java 2 JVMs
are ok - it is the bloated standard library that eats memory.
Also, Java isn't dynamic enough to qualify as a scripting language,
however it still avoids buffer overflows and dangling pointers.
Since Open Office uses Java, running gnucash as an Open Office module
be a performance win for those already running OO (think 64M ram for core
runtime before actually starting any apps).  By requiring gcc, gnucash
could use the gcj JVM, which can run native compiled Java mixed with
interpreted Java bytecodes and native C / C++.  (Uses conservative GC
for C / C++ compatibility, however.)

	The Obscure

Finally, there are lesser known VMs.  I am particularly impressed with Pike.
The problem with these is that they aren't installed by default on
most distros.  The old chicken and egg problem.

	Scheme

What is causing the dependency problems using scheme?

-- 
	      Stuart D. Gathman <stuart at bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.



More information about the gnucash-devel mailing list