Re: Non-C bindings in GNOME

[Seth Nickell <snickell stanford edu>]

On Sat, 2002-08-17 at 16:13, Havoc Pennington wrote:
> 
> Seth Nickell <snickell stanford edu> writes: 
> > On Thu, 2002-08-15 at 20:49, Jeff Waugh wrote:
> > > I would support an expanded "integrate language bindings into the library
> > > module" across all of our libraries. Obviously that's a pretty huge
> > > seachange, and there are various things to iron out. If it works out well
> > > with ORBit2 and maintainers support it, it could be very cool for other
> > > languages.
> > 
> > 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.

I'm not talking about libraries, though I am talking (potentially) about
core GNOME, and also non-core GNOME applications. It makes sense to me
to keep the current things-things-link against stack C-only. We'd still
have C + one other language in each *process*, but of course that's
implicit any time you're using GTK+ with a non-C language.

As for on disk space... hooey! Developer resources are way more valuable
than some paltry number of megabytes.

>  2) Thus we can have C plus ONE language binding used to implement 
>     any non-leaf node in the dependency stack.

Sure, fine. I would be comfortable saying we should only have C in
non-leaf nodes in the dependency stack too.

>  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...

Python seems like a fine choice if you do that, yes. We shouldn't not
(woo hoo, go double negatives) decide useful things just because we
don't want to have an argument. This is the same silly thing that has
kept us using the GTK default theme for so long.

>  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.

Oh lord no.

>  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.

My experience with C++ bindings has overall been extremely positive, and
that in spite of some big road bumps caused by me starting to use them
very early in their GNOME 2 port cycle. I still suspect I have spent a
lot less work to get what I've gotten than I would have spent with C.

>  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.

I agree, splitting them into the various modules is a bad idea.
Including them with shipping core GNOME seems like a good idea to me.

> BTW I don't fully agree with your analysis on why people don't use
> bindings. I think it's because most gnome programmers are C
> programmers, the docs are all for C, and people just don't bother to
> learn the bindings. Also the bindings often lag the C APIs in annoying
> ways or tend to change more often, historically. But the most
> successful bindings have been the really complete and
> actively-maintained onese such as pygtk and gtkmm. Red Hat uses pygtk
> extensively as you know.

If anything I think we may have scared off anyone except "C
programmers". So you're right, everyone working on core GNOME today is a
C programmer (or at least, somebody who programs in C). So what? That's
because you have to be a C programmer to work on core GNOME today.
Writing object oriented code in a non-object oriented language is a time
drain. I'm not looking to use anything exotic (though actually, I'd love
to use Java), just plain old C++.

-Seth