[Mono-list] Re: CLI Comparisons

[Miguel de Icaza]

> 1. Why did you or your company decide to build the implementation?

Its roots are on the GNOME project, and the needs to have a better
development platform for end-user desktop applications.  Here is in more
detail:

    The GNOME project goal was to bring missing technologies to Unix and
    make it competitive in the current market place for desktop
    applications. We also realized early on that language independence
    was important, and that is why GNOME APIs were coded using a
    standard that allowed the APIs to be easily wrapped for other
    languages. Our APIs are available to most programming languages on
    Unix (Perl, Python, Scheme, C++, Objective-C, Ada).
    
    Later on we decided to use better methods for encapsulating our
    APIs, and we started to use CORBA to define interfaces to
    components. We complemented it with policy and a set of standard
    GNOME interfaces for easily creating reusable, language independent
    components, controls and compound documents. This technology is
    known as Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and
    Java.
    
    CORBA is good when you define coarse interfaces, and most Bonobo
    interfaces are coarse. The only problem is that Bonobo/CORBA
    interfaces are not good for small interfaces. For example, an XML
    parsing Bonobo/CORBA component would be inefficient compared to a C
    API.
    
    I also wrote at some point:
    My interest in .NET comes from the attempts that we have made before
    in the GNOME project to achieve some of the things .NET does:
    
        * APIs that are exposed to multiple languages
        * Cross-language integration
        * Contract/interface based programming
    
    And on top of things, I always loved various things about Java. I
    just did not love the Java combo that you were supposed to give or
    take.
    
    We tried APIs exposed to many languages by having a common object
    base (GtkObject) and then following an API contract and a format
    that would allow others to wrap the APIs easily for their
    programming language. We even have a Scheme-based definition of the
    API that is used to generate wrappers on the fly. This solution is
    sub-optimal for many reasons.
    
    The cross-language integration we have been doing with CORBA, sort
    of like COM, but with an imposed marshalling penalty. It works
    pretty well for non-inProc components. But for inProc components the
    story is pretty bad: since there was no CORBA ABI that we could use,
    the result is so horrible, that I have no words to describe it.
    
    On top of this problem, we have a proliferation of libraries. Most
    of them follow our coding conventions pretty accurately. Every once
    in a while they either wouldn't or we would adopt a library written
    by someone else. This lead to a mix of libraries that, although
    powerful in result, implement multiple programming models, sometimes
    different allocation and ownership policies and after a while you
    are dealing with 5 different kind of "ref/unref" behaviors (CORBA
    local references, CORBA object references on Unknown objects,
    reference count on object wrappers) and this was turning into a
    gigantic mess.
    
    We have of course been trying to fix all these issues, and things
    are looking better (the GNOME 2.x platform does solve many of these
    issues, but still).
    
    .NET seemed to me like an upgrade for Win32 developers: they had the
    same problems we had when dealing with APIs that have been designed
    over many years, a great deal of inconsistency. So I want to have
    some of this new "fresh air" available for building my own
    applications. 
    
> 2. What's different or unique about your implementation?

Well, I do not know what you are comparing things to, so it is hard to
tell you what it is that you are looking for.  I can give you some
"attributes" of Mono:

	* A self-hosting C# compiler written in C#, which is clean, easy
	  to maintain.

	* A multi-platform runtime engine: both a JIT engine and an
	  interpreter exist.  The JIT engine runs currently on x86
	  systems, while the interpreter works on Sparc, StrongARM and
	  PowerPC systems.  

	* Supports Linux, Windows and Solaris at this point.

	* The JIT engine is written using a portable instruction
 	  selector which not only generates good code (we are told
	  that we are faster than Rotor, but it is hard to tell) but
	  is also the foundation to retarget the JIT engine to other
	  systems.  

	  The system employed is described in various compiler
	  books and it is very similar to what is described in the 
	  book that covers LCC, the Ansi C retargetable C compiler.

	* The JIT engine supports inlining, constant folding and 	 
propagation,

	* Full support for remoting in the runtime, but the class 
	  libraries are still behind.

	* The C# compiler, the JIT engine and the class libraries are
	  mature enough that the whole system is self-hosting, ie, that
	  it can be fully developed with itself at this point.

	* We are not yet done, and there is a lot of work left to be
	  done

	* We have a great community of developers, without which Mono
	  would not be possible.

	* We will provide an ahead of time compilation mode in the 
	  future.

> 3. On which platform(s) will it run?

Ideally all platforms.  Ximian will make sure we run at a reasonable
speed on x86 systems, so a lot of our work is on optimizing our code
generator for the JIT engine.

Third parties have contributed ports to other systems, and we will
likely be working on a SPARC or PowerPC JITer ourselves in the future. 
We have not decided yet which platform will be next. 

> 4. Are you testing with code built on the Microsoft platform?

Yes.  Many developers use Mono purely, while others are still using a
combination of Microsoft and Mono: sometimes to isolate bugs it helps to
be able to pin point where the problem originates: our compiler, our jit
engine, our class libraries.  So we try to keep things fully
compatible.  As soon as we can point out an incompatibility we file a
bug to fix it later on.

> 5. What (if any) IDE(s) are you planning to ship with the product--or
> which one do you recommend?

Mono will be the equivalent of the .NET Framework: compiler tools and
runtime environment for applications (console, winforms, asp.net).  We
will work with third parties to integrate the development environment
into their product.

Some people like SharpDevelop because it is a light-weight IDE written
in C#.  

Other people like Eclipse/WebSphere and NetBeans/Forte which are both in
the Visual-Studio kind of realm: larger systems, but with a more
complete set of tools for professional developers. 

Eclipse and NetBeans both have open source communities built around
those and big companies backing the code, so you can see a fairly large
amount of development going on there as well as many plugins and
extensions that are available both commercially and freely.

This is a big difference from Visual Studio, because anyone can write
IDE extensions with these projects (even with their proprietary
brothers).  

Eclipse also has a Gtk2 user interface, which means that it is
accessible and fully unicode aware, and integrates nicely with GNOME. 
And finally, GNOME has its own Anjuta IDE, which is based around Bonobo
components, and its goal is to integrate with the existing various GNOME
components.  A lot more focused on building GNOME desktop applications
though.

Eclipse and NetBeans are both cross platform products, and in the case
of Eclipse, the user interface matches perfectly your user interface in
your target system, which makes it a lot more pleasant for users to
start using it.

> 6. Which parts of the framework are you not supporting -- for example,
> Windows Forms, ASP.NET, ADO.NET, etc.?

We have started work on all those three major components, but nothing is
finished at this point.  Windows.Forms will be based on Gtk# for Unix
systems, and on Cocoa for MacOS X.  

ASP.NET is something that we just started looking at, but with the help
of Patrick we got a long way.

> 7. Give a brief description of the primary audience for your
> implementation.

Although Ximian has one specific concern: which is to ease the
development of applications for Linux, and to ease the migration of
developers from Windows to Linux, other contributors (which is
responsible for a large body of the code in Mono) might have different
interests.

So it is hard to answer your questions briefly: as with any other open
source/free software project, the interests of the groups are wide and
different. 

> 8. What are the estimated completion or beta dates?

We do not have any dates to announce at this point.

> 9. How will this product be licensed? Which license will you be using,
> and why?

The compiler is under the GPL license;  The runtime is under the LGPL
license and the class libraries under the X11 license.  

We have considered relicensing the runtime and the compiler under
licenses that are more suitable for commercial/embedded developers if
they wish us to do so, but so far everyone seems pleased with our
licensing choice.

> 10. How many programmers and architects have bee involved in the beta
> development?

Ximian has five full time developers working on various Mono
components.  And about ninety people have contributed code to the Mono
project during the time it has been under development.

As Mono has advanced, contributions have peeked up, as the project
becomes more useful for other people, and the full open source effect
comes into play.

> 11. What has been your biggest frustration with this project up to now?

It has been an extremely fun project to work on, and everyone who has
contributed to Mono has made every minute of it a worthwhile project:
from the people writing code, to the people providing cvs mirrors, to
the people who have setup the daily builds/snapshots, to the people
teaching you new assembly tricks, to those answering questions on the
mailing lists.  

So, it is hard to tell what is frustrating ;-)

> 12. How would rate the support you've received from Microsoft thus far?

Well, I have made some friends at Microsoft, but I do not know if they
are acting as official Microsoft representatives or just plain good
friends.  So far those people I have met have been very nice and
helpful. 

> 13. Have you found any parts of the ECMA specification too vague and
> thus open to interpretation? If so, how are you resolving these
> differences with the other implementations?

I can not think of something right now.

> 14. Will your implementation offer additional functionality that is not
> covered under the ECMA specification?

Yes, as detailed above. 

> 15. What programming language(s) are you using for your implementation?

Cobol.  Mostly Cobol, specially for the JIT engine.

C and C#.

Miguel.