Re: Non-C bindings in GNOME

[Murray Cumming <murrayc usa net>]

On Sat, 2002-08-17 at 22:13, Havoc Pennington wrote: 
> Seth Nickell <snickell stanford edu> writes:  
> > I think this would be fantastic. We have a chicken-and-egg problem right
> > now where application developers avoid non-C bindings (in my case, I
> > would rather use C++ or Java) because distros often do not include some
> > set of these bindings.
> 
> Here are my objections.
> 
>  1) If core GNOME is written in lots of different languages, it will
>     be huge, and not interoperate with itself. Each binding stack is
>     several megs of additional on-disk library, because we are doing
>     manual (partially-automatic) static bindings instead of dynamic
>     bindings a la .NET. The situation with garbage collection,
>     threads, derivation, etc. with multiple languages in one process
>     is highly, highly undefined; it's somewhat broken even within some
>     single language bindings at the moment, from what I've heard.
> 
>  2) Thus we can have C plus ONE language binding used to implement 
>     any non-leaf node in the dependency stack.
> 
>  3) Which language binding will that be? ;-) I would personally vote
>     for Python due to strong qualitative difference from C,
>     unfortunate licensing of Java, and other reasons, but who wants to
>     have this argument...
> 
>  4) For leaf nodes (applications), using binding-of-anyone's-choice is
>     more feasible but if we use 4 add-on different bindings, it is
>     still going to add 12,15 megs of bloat to a running desktop.
> 
>  5) I do not believe that we will really save time on bindings in the
>     short term, because they also have a cost in extra kinds of issues
>     to debug and other overhead.
> 
>  6) The bindings have separate maintainers and are nicely modularized
>     right now. We exploded libraries into lots of small packages for
>     GNOME 2 and that was the Right Thing. If you pack stuff into
>     single packages, the maintainers of sub-pieces disappear. This
>     phenomenon has been seen hundreds of times - I can't tell you
>     _why_ it happens, but I can tell you it definitely _does_
>     happen. It's better to keep things orthogonal and give people
>     their own little domain.
> 
>     In other words if it's right to split libgnome and libgnomeui,
>     it's equally right to split out the language binding packages.
> 
>  7) "forcing" bindings on people in this way will be a big
>     controversial distraction and suck up developer time, 
>     and 2.2 is about USER FEATURES, please.
> 
>  8) we don't want bindings to delay any release, or complicate ABI/API
>     issues, and if they are packed into the core packages we might
>     e.g. have to delay 2.4 for a binding to catch up to GTK 2.4.  That
>     would be unfortunate. I'd like to see minimum modules on the
>     critical path to release the core user environment.

I agree with this. The language bindings need to prove themselves, and
being part of official platform deadlines won't assist much in that. It
would add unacceptable delay to releases.
 
> So that is short term why we should keep them separate.
> 
> Long-term, the reason is that semi-automatic partially-manual static
> language binding stubs are wrong. We need to be on the Mono/XPCOM/UNO
> model of doing this.

I doubt that it's possible to find a common ground for all programming
languages, and it's clear that the current VM/CLR ideas do not succeed
in this. It might cover lots of intentionally-under-featured languages
(e.g. Java, VB) and interpreted languages (e.g Perl, Python), but not
all programming languages. .NET's "Managed C++" is a perfect example of
this, and I don't want to go there. 

-- 
Murray Cumming
murrayc usa net
www.murrayc.com