Re: [Evolution-hackers] usage of C in evolution

[Jeffrey Stedfast <fejj ximian com>]

On Fri, 2004-05-21 at 08:15, Stan Pinte wrote:
> hello,
> 
> I have not looked at evolution 1.5 source tree, so maybe my message is
> out-of-date...
> 
> but I just lost like 20 hours trying to debug the
> evolution-vcard-importer component in 1.4.6-2...
> 
> and it is deadly slow, because:
> 
> -It is a bonobo component, and it is hard to debug it, because I find no
> way to start one in gdb, and to make evolution connect to it, etc.

you should be able to simply start the component under gdb just fine if
it's an out-of-proc component. If it's not, then it's no different from
debugging a shared library in the evolution process.

> -It is written in C!!!!!!

I happen to like C.

> 
> My question is: it is nice to have a CORBA abstraction layer between
> frontend and backend components, but why write these backend components
> in C? 

because:
1. we know C
2. it means someone can write bindings for them for different languages
if they so choose
3. the rest of the system is in C

> 
> --> I think python would be much more suitable for that task: dev would
> be 10 times faster, and debugging 10 times cheaper. 

I think NotZed's reply says it all.

> 
> I perfectly understand that for performance reason, some core graphical
> components, or some heavily used algortim must run natively, but we can
> wrap them to use python as glue...

pain. paaiiin. paaaaiiiiinnnn!!!!

don't you have it totally arse backwards anyway? would make more sense
to me to write the backends in C and the front-end in python (assuming
you were to mix languages, which I don't particularly care to do).

I mean, if you are gonna write the backend in python, why stop there?
makes no sense to write UI in C if you are gonna write everything else
in a higher level language.

> 
> look at gnucash: the user interface is pretty good in my opinion, and
> they do it like this: core UI components in C, wrapped using G-Wrap, and
> glued with Guile (GNU Extension Language)...so that all business logic
> is really easy to understand and to debug!!!!

yes, lets look at gnucash. oh wait, I can't because it has so many
packaging conflicts with all the odd versions of this and that that it
requires. it needs a special guile that conflicts with the guile
versions that other stuff uses, etc.

As another point against using python here (well, more specifically,
multiple languages), I never liked the idea of mixing languages. It
makes the system inconsistant, harder to debug and harder to write code
for (I gotta know more languages and know how they interact! and I gotta
know multiple debuggers, etc).

Jeff