Design Decisions

[Derek Atkins]

Ok, you've roiled my blood by ignoring the facts, forcing me to
respond to your drivel.  (Never a wise move)

I really have only one thing to say in response to this, and I'm
going to say it loudly because it appears you don't understand when
it's written plainly: VERY LITTLE OF GNUCASH IS WRITTEN IN SCHEME!

There, I've said it.. AGAIN!  Only 13% of gnucash is written in
scheme.  That's an awfully small number.  The vast majority (80%) is
in C, and the size of the C code is growing MUCH faster than the size
of the scheme code.  So, anyone who complains about how hard scheme is
can, perhaps, just ignore that 13% of the code (or take one day and
learn the language -- it's really not that hard!).

Personally I have no problem with having swig bindings.  The problem
before (historical fact) was that the swig bindings to scheme were not
sufficient to do what the developers wanted at the time (this was
before any of current developers were involved).  Today the problem is
that nobody has stepped forward and exclaimed to the world "Never
fear!  I will maintain the swig bindings!"  so they have fallen into
disrepair as the rest of the code has moved forward.

Are __you__ volunteering?  If not, then get off your soapbox and let
us continue hacking, or find us someone who WILL volunteer.  That is,
after all, what we're looking for -- volunteers.

-derek

Charles Goodwin <charlie at xwt.org> writes:

> I've been a distant lurker for some time on the GnuCash project.
> 
> Some conversations have cropped up and died down on reasons for
> GnuCash's woes with regards to it's developer base.
> 
> They all have a common theme.  They all end with a GnuCash developer
> unequivically stating: "We're not changing project direction."
> 
> That's fine, it's *your* project after all.  But you cannot then go
> and complain in the next breath 'we don't have enough developers' when
> you refuse to change your own situe.
> 
> This is no rant, but I'm going to be blunt.  Few people know
> Scheme/Guile and fewer are prepared to learn it.  Pursuing purely
> Scheme/Guile extensions with GnuCash is tying your own hands behind
> your backs.
> 
> "But we can't rewrite GnuCash or maintain lots of language bindings!"
> 
> No, but you can do what some savvy developer already attempted in
> GnuCash, use SWIG.  Forget the pure Scheme/Guile bindings and use pure
> SWIG instead, which supports Scheme/Guile bindings anyway.
> 
> What you, the lead developers, need to do is to put your heads
> together and decide on what is vital for the future of GnuCash.  What
> do you need to do to attract users and developers.
> 
> I'll save you some time.
> 
> Lowering the barrier to entry should top of your priority
> list. Adopting SWIG (which maintains Scheme/Guile whilst allowing
> Python/Perl/Ruby) would help tremendously.
> 
> Gnome2/Gtk2 support should be next.  The world is a vain place as well
> as a resource begrudging place.
> 
> Reviewing and reorganising the architecture of the GnuCash codebase is
> something you should not delay any longer.  Whilst I have no real
> perception of how well designed or abstracted the various parts of
> GnuCash are, the way even all you developers talk about it is as if
> it's one giant legacy footprint.  What can be it's own library?  What
> can be used by other applications?  What in GnuCash is done better
> elsewhere and how can that be used?
> 
> Another, more controversial, thing to think about is how the GUI is
> written.  Could rapid progress be made with something like PyGtk/Glade?
> 
> You need to get a decent perspective on things.  The Gnome team looked
> at 1.4, thought, "we can't easily do what we want with this code
> base." They identified the major changes needed and gutted the
> original codebase, saving only the savable.  People savaged the
> initial result (Gnome 2.0) but it's becoming evident now (Gnome 2.4
> beta1) that they did what was best for progress and best for the
> project.
> 
> Sometimes you have to take a step backwards in order to take one
> forwards.  If you embark on a redesign and adopt the simplest,
> quickest route, it's very possible even with a handful of developers
> to produce something amazing.  Look at AbiWord.  AbiWord2 is a
> complete redesign of AbiWord1 and is far better for it, and they only
> have a handful of active developers.
> 
> Plus there's nothing like a rewrite to generate a bit of buzz and
> attract a few lurker developers who can't get in on the act with the
> original codebase.
> 
> Nobody will do this for you with a fork of GnuCash because there is
> not a group of dedicated developers disatisfied with the project
> direction -
> other than the lack of abundant help.  So it's up to you to do it, to
> help yourselves so that others may help you in the future.  The
> AbiWord team took a year out to do their redesign and rewrite.  That's
> the kind of sacrifice you'll have to make.
> 
> Of course, you could keep moaning about people not being willing to
> learn Scheme or run a legacy Gtk1 application, but if you do then
> don't expect anybody to feel sorry for you or the fate of GnuCash.
> 
> That's the cold, hard truth.
> 
> - Charlie
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available