Note (18th march 2001): Since this article was written, a gnome-bindings mailing-list was created, which purpose is to make it easier for C developers to reach the various binding maintainers. As of the time this note is written, however, it seems to be pretty dead, as shown by the archives. Coding guidelines to make wrappable C APIs have been issued, which should simplify the life of binding maintainers, if they are followed. I'm afraid though, the bottom-line is still that programming for Gnome in anything else than C is far from immediate and requires a significant added effort.
Below is the original article.
In a recent interview with the BBC, Miguel de Icaza, the Gnome project leader, made the assertion that KDE has no future because it is tied to one language (C++) while Gnome isn't.
As one of the maitainers of Gtk--, (C++ bindings to GTK+ and the Gnome libs), I'd like to add a few comments.
Miguel seems to imply that Gnome not being tied to a particular language is a great advantage, and nothing else. While nobody would dispute it is an advantage, I wish to show that there are also some drawbacks to this, which certainly can't be ignored.
The first drawback is that a binding is another layer of code. I don't mean performance issues, as the overhead is in most cases negligible as far as the user is concerned. I mean another layer which needs to be debugged, documented, and maintained in sync with the library being wrapped.
As such, each language binding is in itself a small OSS project. While it can be kept alive if properly maintained, for whatever reason it can also stop being so, or suffer extensive delays with regard to the library it wraps. Rather than being the exception, this is so common that the gut feeling of a potential developer in front of a language binding is "it will always miss something". As one of the Gtk-- maintainers, I've experienced this reaction many times.
Another drawback is that a language binding may just plain suck or at least displease the developer who would like to develop an application using that language. There is no one true way to wrap a C library in another language, so another developer might be tempted to create his own. As such, there are three C++ wrappers for GTK+ (VDK, wxWindows, and Gtk--), and two Objective-C ones (see the GTK+ homepage). In the case of a Gnome app, Gtk-- is currently the only wrapper also providing bindings for the Gnome libs (although they are far from complete). But given the direction VDK is taking, it would be logical for them to eventually provide such bindings as well. And already, a developer who wants to write a C++ application with GTK+ has first to decide which one of the wrappers he'll use.
For the developer using it, a language binding is also another layer which his code depends on, another library to install and maintain on his machine, another potential source of bugs and another thing to learn. Even if the translation from the library to the wrapper is merely syntactic, a wrapper will always have its own features, taking advantage of those of the language it's based on.
Because of all this, it would be very impractical to develop a major Gnome application in an "exotic" language because such an application can't afford the dependency on that language, and the whole environment it requires (native libraries, bindings and such). Miguel himself admitted to this with his comment that ended his proposal for a Gnome mail client : "Bertrand has been working in such a beast, perhaps we can reuse some of his code. I am just a bit concerned that the implementation is in Objective-C, which means that people need an Objective-C compiler on their system to compile it."
Of course, this also implies that, for a user to run it, he would need the Objective-C runtime environment to be installed. While all Linux distributions provide it (it's a part of gcc), on other Unices that means installing gcc itself.
That's also one more set of libraries to be loaded along with the application when it's run. Should several important ones be written in different languages, the impact on the resources would be quite significant.
A language binding is certainly another open door for a developer to participate in Gnome. But if he chooses that path, it's also another point of potential failure and another constraint on both him and the end user. These added requirements add a heavy counterweight to the advantages. As a result, Gnome is de facto "tied" to C just like KDE is "tied" to C++ : In both cases, other languages can be used, but chances are that no big application will use them.