Is there anything *enjoyable* about our development process?

[Josh Sled]

On Fri, 2005-10-14 at 15:39 -0400, Stuart D. Gathman wrote:
> 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.  

Actually, it's this assertion I challenge.  80% of the codebase right
now is in C, and it should be 100%.  I don't see a need for any of it to
be in a scripting language.

I could see SWIG (conditionally) used to provide bindings to the core
logic in a number of languages, for external projects to interface
against.  But think the core code, UI and the official distribution
should be simply C.  I could even see this change back over time, as a
new major component is developed using those bindings.  But right now we
must focus on simplicity.

A notable exception is the reports, which can be more
templates-iteration-and-basic-control-flow than embedded-scripting.


> 	Scheme
> 
> What is causing the dependency problems using scheme?

- Simply the dependencies themselves (guile, slib, g-wrap)

- The natural impedence mismatch between C and Scheme.

- The lack of layering we have now, where C and scheme call back and 
  forth freely, and parts of the system are defined primarily in scheme.

- Gnucash init is actually a scheme script that loads a bunch of 
  modules and init, but then calls into a normal C/GTK event loop.  
  Which makes it a PITA to debug (the C code is fine, but especially 
  as the calls go back into scheme code...).

Also, frankly, it just puts people off.  I love scheme, and I think
every developer should learn it; it's one of the single most important
things in computing, period.  And I'd be fine if gnucash was 100%
scheme.  But this 80/20 thing is distracting and annoying, especially
given the real, inherent complexity that gnucash has to deal with.

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`