Recently Miguel de Icaza (founder of the GNOME project) made some remarks about his hopes for basing future GNOME software on Mono and C# which drew a lot of surprise and ire. In this email to gnome developers, Miguel explains his statements, clears up some misconceptions, and makes some excellent points about software development.
Miguel starts by pointing out that his statements were taken out of context; and that regardless, he has no ultimate control over whether GNOME adopts his ideas or not.
GNOME is not adopting Mono or .NET as an implementation technology. The headline from the Register is misleading
I am not the GNOME foundation or control GNOME like Linus controls his kernel, I am just its founder and a contributor.
He goes on to talk about .NET, and software reuse (emphasis mine):
He points out that UNIX and windows share the problems of code duplication and API inconsistancy (emphasis mine):
This technology allows programming languages to be considered on the basis of how they will perform for a given task, and not based on the runtime libraries that you will depend...
So no longer should a software engineer pick Fortran, because that is the only language where his math libraries are available: he can now pick the right language for the problem at hand.
Microsoft has terrible APIs to code against...
To make things worse, an evolution of APIs, components, memory management contracts and patched up versions of COM have made the platform horrible.
Microsoft has injected fresh air into their platform by building and designing a new programming platform that addresses all these pains...
Now, the Unix platform, GNOME included has some of these problems: our APIs have been evolving. Libraries have been built by disconnected groups (PNG, JPEG, Gtk+, Xml, Bonobo, CORBA spec apis, etc) and the end result is that a developer eventually has to learn more than he wanted to in the course of developing a large application.
And now we get to the crux of the matter:
Large software projects expose a set of problems that can be ignored for smaller projects. Programs that have long life times have different dynamics when it comes to memory management than smaller programs.
There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists.
He continues, explaining that GNOME is not going to be re-written in C# or anything silly like that. He does make the point that using .NET, it is very simple to extend existing applications in any language you want to use.
Finally, he reminds the audience that GNU itself was originally all about re-implementing proprietary technology; and that even if MS extends .NET beyond the ECMA-standard compnents, the Free Software community will still have a useful new development framework. Nothing will be lost by writing a free implementation of .NET.
GNU is a free re-implementations of Unix. Linux is a re-implementation of the Unix kernel. Before the advent of Linux and the Berkeley Unix, Unix was a proprietary technology, built by ATT (which back in the day, was a monopoly).
Still, developers took what was good from Unix, and reimplemented a free version of it. Down to the Unix programming language: C...
Think of Mono as following the same process: we are bringing the best technology out there to our beloved free software platform...
There is the issue that we might not be able to keep up (right now, we dont, as .NET Framework 1.0 is already out there, and we are, well still underway). Also, theoretically there is the risk of a given API being unimplementable on Unix.
Even if that is the case, we still win, because we would get this nice programming environment, that althought might not end up
being 100% .NET Framework compatible, it would still be an improvement and would still help us move forward.
Now, as a hacker, I believe that being able to pick a language based on it's basic merits and your own proclivities, rather than the libraries available for it, is one of the greatest holy grails of software engineering. I don't know how many times I've thought to myself "gee, I'd love to code this in Ruby", only to wind up coding it in Perl because Perl was the only language with the existing libraries I needed for the job. As a dyed-in-the-wool OO programmer, it's sickening to see every new language reimplement hundreds of basic libraries from scratch. Just look at the scripting languages: Perl, Python, TCL, Guile, Ruby, etc... each one has it's own, incompatible set of libraries which do effectively the exact same things. And the developer communites for the newer languages, rather than spending their energy on creating brand-new, never-before-thought-of libraries, are busily re-doing all the work that went into something like CPAN, making the same mistakes, finding the same bugs, writing the same code.
One would think that NIH syndrome would be something only encountered in the competitive corporate world, what with Free Software's ideals of share-and-share-alike and being able to build on other people's ideas. But the amount of code duplication is staggering - just search on freshmeat for Gtk+/GNOME mail readers sometime. I've encountered the attitude myself in the Ruby community. I've brought up the subject of creating a Ruby-to-Perl bridge, so that Ruby code could use CPAN libraries (similar to the Perl Inline::* libraries), to be met with blank disinterest. Instead, I was told to add the libraries I needed to a public wishlist, so that Ruby developers could tackle re-implementing them when they have the time.
I'm sorry, but this is not the attitude of a Pragmatic Programmer. In accordance with the First Virtue of a programmer, Laziness, hackers reuse code whenever possible. I don't want some poor developer to have to go and recode and debug some boring library, making all the same mistakes the original implementor made all over again; I want to pull in an existing library from whatever language it was written in, and use it as if it were a native library. I want to write libraries in C++, back-end server code in Java, a web interface in PHP, a desktop GUI in Python, and have it all work together seamlessly, without having to write reams of interfacing code. This is the dream that Miguel and his Mono coders are in the process of making reality; and I say, more power to them.