Re: Time to heat up the new module discussion

Replying from off-list, pardon the break. At the encouragement of
various important parties on #gnome-hackers, I am posting a copy of this
from my blog in an effort to help focus the Pro/Con-Mono argument. I am
not taking any side. This is only a summary.

So, I spent two hours reading every email sent in April, May and July
about including Mono as an official part of the GNOME platform and
Tomboy as an official application of the Desktop. You might be thinking,
"Two hours is a lot of time to waste on this," but this argument is
really, I think, one battle in the much larger war over whether JIT
languages can be general use languages. Further, there are a lot of side
issues which are complicating this.

Now, first, let me summarize - as objectively as I can - the two sides
of the Mono argument. I have some experience in both camps. As the
gnome-games maintainer, I oversee the maintenance of lots of C
applications (and one Scheme); some of them very hard to maintain. On
the other hand, I have written several commercial GUI apps. in GTK#
using both Glade# and Stetic.

      * Pro-Mono people are arguing: 
              * Lots of cool applications and innovations are happening
                in the Mono camp. There's apps. like F-Spot, Tomboy,
                Beagle, and Banshee being written way faster than they
                could be in C. Anti-Mono folks generally agree but think
                that high level languages should only be used for
                prototyping (the benefits of RAD don't outweigh the
              * ISV's and corporate environments will benefit from the
                Monodevelop tool and the general availability of more
                RAD tools on the GNOME platform. Anti-Mono folks
                generally agree but argue that being able to install
                these separately isn't a barrier to their use for this
              * Mono needs the GNOME endorsement of official inclusion
                to heal the community divisions over it. If we don't
                include Mono, the community will split further.
                Anti-Mono folks argue that - even if Mono is included -
                distributors like Mameo and RHEL are going to
                pick-and-choose the parts of GNOME that fit their
                requirements (official inclusion really doesn't mean
                much in the way of platform endorsement).
              * Python is there, so why not Mono? Anti-Mono folks argue
                that - in some ways (Deskbar) - including Python was a
      * Anti-Mono people are arguing: 
              * Mono applications will use, generally, at least twice as
                much memory as an equivalent C application. In some
                cases more because of the overhead of the VM. If such an
                application were part of the panel, for instance, that
                would be a huge drain on memory and start-up times.
                Pro-Mono folks agree about the memory figure but argue
                that the pros outweigh the cons. Pro-Mono folks disagree
                about start-up times and also argue that users will have
                to choose to enable those panel applets. Also, deep in
                the thread Miguel pointed out that Mono apps. can be
                compiled "AOT" which would allow them to share the
                "overhead" in the same sense that shared libraries work
                in C. (I should also note that some Anti-Mono folks
                seems to have had bad experiences with Beagle running
                away with their RAM - especially on older systems.)
              * C#/Mono is a Microsoft invention and therefore it might
                be used as a weapon against GNOME. Pro-Mono folks point
                out that this has already been argued against many years
                ago and that the argument is closed.
              * Mono is just like Java and, despite Java existing for a
                decade, no compelling desktop applications exist that
                run on Java. This shows that JIT platforms are generally
                too slow. Pro-Mono folks point out that the freeness of
                Java has been a factor but, despite this, GCJ/Classpath
                is progressing and some counter examples are Eclipse and
              * There is a general effort to decrease GNOME's footprint
                and including Mono would continue to undermine that
                effort. Pro-Mono folks argue that optimizations are good
                all around and that, again, the pros of rapid
                development outweigh the costs. Also, Pro-Mono folks
                point to Evolution as an example of a C program that is
                clearly a memory hog.

SO, what is my opinion? Well, probably no one cares and I have to say
that I don't know which side to take, right now. Both sides are making
some compelling points.

What IS clear is that neither side seems to be arguing with very good
real-world examples to back up their performance claims. For instance,
no one mentioned the widely praised (with grains of salt) Shootout
benchmarks of which all the languages in this discussion are included.
Also, Anti-Mono folks keep saying or implying that, before Mono, C was
the only language in GNOME. I would like to remind them that
gnome-games, long included by default on every Linux distribution,
depends on Scheme (the guile bindings).

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]