[RFC] A differnt options system

Stephen Evanchik evanchsa at clarkson.edu
Wed Feb 16 20:09:25 EST 2005

On Wed, 2005-02-16 at 13:55 -0500, Chris Shoemaker wrote:
> > Granted, it's MUCH easier to use them from scheme than it is to use
> > them from C, but that's just due to the way it was designed.
> Yes, you're exactly right.  But who do we want to attract to hack on
> gnucash?  more scheme programmers or C programmers?  We should make it
> easier for whoever we want to attract.

Well, I know C and Scheme and at the risk of being a bit of an elitist:
a competent programmer should be able to pick up a language over the
course of a week. It's not reasonable to expect them to be a master at
the end of the week, but they should be able to stumble around and use
pre-existing code. An iterative process is key.

"You" in the following context is really any developer reading this: 

If you are having trouble using the APIs you should confirm whether you
are understanding them fully. I doubt that the designers of the API
intended it to be difficult to accomplish routine tasks. Ask questions
and seek guidance before expending a tremendous amount of work on
something that will be shot down because it is too narrow an
implementation or solves the wrong problem entirely.

> > 
> > >     they're not going to be real impressed with the Gnucash codebase.
> > 
> > That's true anyways.  Find 10 "new" developers and you'll probably get
> > them pointing at 10 different ways the gnucash codeback sucks.
> You're right, but I see two problems: 
> First, for every ten "new" developers discovering that gncuash
> codebase sucks, only one will sit down, figure out why it sucks and
> try to improve it.  The other nine will say "gosh, this stuff blows my
> mind; I'm gonna go work on something where I can make forward progress
> without spending 3 months grokking this mess in the dark."  People
> like seeing the fruit of their labor -- it's human nature.

Well, at this point it is probably better for us not to have 9 people
asking questions and bombarding the list with patches that aren't

Changes should be interative in 95-plus-percent of development cases.
Especially in the case of working with something that is functional
albeit flawed. 

> Second, we don't have 10 new developers.

I'm one.

I don't know much about the options code, but I do know that some of
your ideas may be important and quite relevant to making gnucash better.
Is it possible to incorporate them in to the existing code base even if
it takes longer and may be more difficult? 


More information about the gnucash-devel mailing list