Is there anything *enjoyable* about our development process?

[Neil Williams]

On Friday 14 October 2005 8:54 pm, Derek Atkins wrote:
> Quoting Martin Preuss <aquamaniac at gmx.de>:
> > What frightens me most is scheme...

Join the (v.small) club! (int i = 1; i++;)

I have no knowledge of scheme and despite many appeals from Derek and others, 
I have absolutely no intention of learning it! 

What little I've seen and tried to follow has put me off - along with the 
perception that anyone who uses emacs must like lisp and can move to scheme 
with graceful, effortless ease. Well, sorry, I cannot use emacs. I've tried 
many times and it just does not make sense to me. Don't let's start any flame 
wars here, but I am happy with vi.

> > I'm quite firm in C/C++, but having 
> > to learn another language just to get some things into Gnucash is
> > currently no option for me (I simply don't have the time right now).

Absolutely agree. 100%.

> I wish I could stamp out this FUD about GnuCash.  The archives and
> the FAQ try to be quite clear on this:
>
> 1) GnuCash is 80% C
> 2) Scheme is limited to an extension language
> 3) Scheme is only used /strongly/ in the QIF Importer and Reports

?? gnc-module ?? The modules are written in C but it is scheme that loads them 
- it breaks the flow and makes it hard to follow the program in the source.

What was that quote about 20% of a project requiring 80% of the effort?
;-)

> To sum it up:  unless you're hacking on the QIF importer or a Report,
> it's VERY VERY VERY unlikely you need scheme to do what you want.

Do what you want, maybe. To *understand* what you are doing and where it fits 
in the program flow, sorry, I strongly disagree. I know to my cost that 
making changes without that understanding only causes grief for everyone.

Scheme/guile/gwrap get in the way of all manner of processes within the tree 
*when the developer doesn't already know scheme*.

It IS a significant barrier to new developers, it is off-putting because it 
"hides" essential components of program flow in a form that a C developer 
cannot easily follow.

One of the most important stages in learning a new program is to have a clear 
understanding of how it gets from main() to return 0; gnucash uses a bash 
script and guile and I still don't understand *anything* about how it gets 
from $ ./gnucash to gnc_engine_init().

I've been recommended to learn scheme so many times within gnucash but NEVER 
outside it. Why should new developers be treated in that way? I've mentioned 
this before, we are not flushed with offers of new developers, we cannot 
afford to make gnucash *less* appealing than A.N.Other project. People will 
gravitate to one of two projects:

A) The one they enjoy working within the most, or
B) The one they REALLY need to fix for some personal itch.

Developers who join for reason B will be pre-occupied with their own needs, 
reticent about taking on things like scheme (because they just want to 
scratch their itch) and prone to leaving immediately their need is met.

The original article that started this thread was all about making gnucash 
appealing for reason A.

I enjoy working within QOF - that is my emphasis and all my work in QOF is for 
reason A. 

Unfortunately, I am working within gnucash more for reason B than reason A. I 
sincerely hope that this will change and I want to encourage a climate that 
tips the scales in favour of A.

Learning scheme just to get under the skin of gnucash is simply too much of a 
barrier to many prospective developers. I guess that may be why it's been so 
hard for me and why I've had so many problems getting under the skin of 
gnucash. Those problems have inevitably caused problems to other members of 
the team.

Scheme is another of the hidden barriers in gnucash. Others could be:

1. Hard to follow code layout - src/engine in particular has caused lots of 
confusion on this list when trying to relate to QOF. CVS is the main problem 
here, preventing file system re-organisation. (I like CVS but I recognise 
it's problems too).

2. Confused function naming conventions and file naming conventions. (Again, 
filename problems are related to CVS - function names are just historical and 
a lack of time to change them).

3. Lack of developers (catch 22 - the fewer active developers, the less time 
is available to help prospective new developers).

4. This isn't gnucash's fault but such a large project is a *difficult* one to 
take on. We can't reduce the codebase but I feel we all need to make it 
easier for new developers to get "under the hood". One BIG problem for me has 
not been "code" but *code management*. Each developer here has their own 
scripts and tools, procedures and routines for updating from CVS, test 
builds, separate test trees, favourite editors, tab conventions, etc.etc. 
Some of this DOES need to be formalised somewhere. I've lost count of the 
number of commits where one of the other developers has rounded on me for 
some problem that I had not anticipated. We can't all telepathically know how 
to manage the code and the commits. Sometimes I do wonder if it is worth the 
(seemingly inevitable) hassle. I should not dread making a commit, or have to 
set aside most of the following day to answer queries and explain why I did 
certain things. Maybe it's all down to me being self-taught but if the 
unwritten conventions of a computer science degree are seen as unbreakable 
rules, then those who have a different degree of training need to know - in 
advance - how to check for those. Yet at the same time, we can't bombard 
prospective developers with a 70kb HOWTO. This is the area that causes me the 
most angst but I have no real answers, just lots of messages in the archives.
:-(

Despite all that, I've been lucky and I am extremely grateful for the 
encouragement provided by Derek and others but if gnucash could dump the 
guile/gwrap dependency I would be a very happy developer. I'll settle for 
removing guile from all areas EXCEPT the ones highlighted by Derek above: QIF 
importer and reports. (QIF != QOF!)

Sadly, there is more work to be done before that becomes possible and most of 
it is not urgent for G2.

> > But since Gnucash uses scheme for so long I believe there must be a good
> > reason for using multiple languages in such a big project, so currently I
> > must resign.

That is a desperate shame, Martin. Please reconsider. I may upset the other 
developers (often) but I can make a contribution to the codebase *without* 
knowing any languages except C. (I'm OK with perl, bash etc., but I haven't 
specifically needed those for gnucash.)

Hacking on gnucash is a big enough learning process on it's own, don't be put 
off by the scheme, you don't need it and although it makes things hard 
sometimes, you can work without it - you just need a thick skin!

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051015/601ca094/attachment.bin