Language choices for the GNOME system

[Miguel de Icaza <miguel nuclecu unam mx>]

[ This is about the debate of programming languages in gnome-list ]

There are a number of reasons why the GNOME project chose the C
programming language.  

The decision to use the language for our core and foundation
libraries, is something that we decided for the specific task of
writing GNOME.  Some of the rationale, tradeoffs and reasons might or
might not apply to other projects.

* On code complexity

   People who contribute to Free Software projects (Open Source) are
resources that might appear one day and vanish the next day.  There is 
no way to ensure that somebody is going to stick around for any time.

   We want people to quickly understand the code: ie, make the learning
curve smaller.  If the code is simple enough, hackers can become
productive quite quickly (ie, hacking new code, improving existing
code, or fixing bugs in the code).

   So a big goal of GNOME is to keep software maintainable.  And this
is one of the major goals.  Keeping software simple to understand is
more important than having lots of features.  Some of us have learned
this the hard way.

   There are a number of ways of achieving this goal:

	* Write libraries to handle common tasks.
	* Split functionality in different components (CORBA or libraries)
	* Reuse code in libraries. 
	* Avoid code obfuscators as much as possible.

   Thread programming is a common code obfuscator: the original author 
might know all the interactions of his code, and might know how to
handle them, but to most newcomers to the code base, it is just a very 
obscure thing, and it forces people to understand the whole model
before being able to modify, extend, fix the application *correctly*.

   C++ is a large language.  We do not want to demand from people to
understand fully the language before they can become productive in the 
GNOME environment.

   A common way of addressing this problem is asking people to stick
to a subset of the language (for example what the Mozilla folks have
done for their XP code).  The problem is that then you should then
understand C++ and on top of that remember which things you should use 
and which ones you should not use.

   Besides that people will tend to deviate "just a little" from the
accepted subset of the code.  Now, if you put together 100 hackers
that just "deviate just a little" from your spec, after a few months
you end up with a program that requires people to understand every
single feature of the language to become productive.

   Now, I personally have problems with C++.  It is a language that
has evolved over time: there was no clear goal at the beginning, nor a 
clear goal during its development.  What we have now is a mix of
language features, many of them good features.  But sadly, the
language lacks some sort of "internal" consistency.  This is purely
from a taste-point-of-view.

   Contrary to what most people think, Ada95 is a much nicer, simpler
and cleaner language than C++ is.  And Ada95 has nice bindings for GTK 
(and I think GNOME as well). 

   Now, from the binding point of view:  C alone does not provide a
good framework for writing language bindings.  We have a document that 
explains how to make the API for our library code be simple to wrap
for language binding people.  

* On Object Oriented Programming

   Object Oriented Programming is not a solution to every programming
problem, it provides some nice abstractions for implementing code that 
follows *some* design patterns.  

   Typically, OOP is useful within a complete framework, and this
framework not necesarly spans the whole project.  Code reusability is
not very good: it is usually bound to the language in which the
class/object is implemented.  And exporting this mechanism to other
languages is usually painful and hard to integrate well.

    That is why I am so excited about Bonobo-based component
programming: because components can be reused and implemented in
various languages and reused in far many more cases than any OOP
class. 

Best wishes,
Miguel.
-- 
miguel@gnu.org