[Mono-list] Has Mono delivered?

Wed Jan 11 07:31:07 EST 2006

On Tue, 2006-01-10 at 22:53 +0000, Dave Murphy wrote:
> I came across this quote from Miguel:
> 
> "One of the reasons that we developed Mono was because we wanted to
> have better tools to develop software" – Miguel de Icaza
> 
> ...and I was wondering: does Mono really provide a better environment
> for developers?

Something implied by "better tools to develop software" is "more
productive developers."  Mono *does* do this, as is seen with F-Spot, an
imaging application written entirely by one person, never mind all the
other useful Gtk# apps that have shown up (Tomboy, Blam!, Beagle...).

> I don't want to get into a debate about language or framework
> features, but instead focus on the experience. To me there's a lot of
> potential being missed - the emphasis still seems to be on using
> 'standard' build/config tools (make, autotools etc.) - which
> complicate cross-platform development - and reliance on the
> distributions for packaging and satisfying dependencies.
> 
> Are enough "better tools" being provided, or is there more that can be done?

There is *always* more that can be done.  The question really is, what
should be done, and will it actually help?

There is an emphasis on autotools because developers are familiar with
it, and it has minimal dependencies.  If you prefer, you could use NAnt.
Or you can use MonoDevelop's project files.  There are a number of
solutions that exist.  However, all alternative solutions complicate
other things, such as requiring some tool be installed (NAnt,
MonoDevelop).  This doesn't matter if the tool is already installed for
you, but if you're installing from scratch it's one more thing you need
before you can work.  This is the advantage of autotools -- it's
everywhere.  Alas, it's also non-ideal for Win32.

As for "reliance on the distributions for packaging and satisfying
dependencies", what would you prefer?  You mention CPAN later.  The
problem with CPAN (and similar systems afaik) is that it *doesn't*
integrate with the underlying packaging system.  This means that if an
update is available (e.g. security fix), you *won't* know it's
available, it *won't* be installed, and you'll be SOL unless you keep up
on ever project you depend on (and who does that?).

This is *bad*, really.

The only advantage of CPAN-like systems is that it's easy to use.

Consequently, "reliance on distributions" is a good thing -- you get the
entire package dependency tracking & update mechanism for free.

The only problem is that this isn't always user-friendly.  There are
people working on making this easier -- see http://www.autopackage.org/.
Bundling private assemblies with your app also helps cut down on
dependencies, which is why they're preferred.