Right, "Type Erasure" means that none of the semantic information is preserved in the produced bytecode or metadata.

This has several problems, for example, the following is invalid in Java:

class Stack {
        T [] storage;

        Init ()
        {
              storage = new T [20];
        }
}

You might want to read "Generic Gotchas" for Java. There is no such problem with the C# version as they are first class citizens:

http://www.ibm.com/developerworks/java/library/j-jtp01255.html

The implementation is so arcane that it requires documents like this encyclopedic FAQ:

http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html

Or even Sun's Ken Arnold stating that "Generics are a mistake":

http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html

None of this problems happen in C# and .NET.

I cant be incompetent and at the same time succeed in derailing Linux application development. Pick one.

Your rage prevents you from making a cogent argument though; I did not "derail" any application development, if anything, I created a project that many people seem to enjoy using.

The fact that you can not tolerate that others do as they please, and that you feel that people need to obey is merely a manifestation of your fascist tendencies.

Both the JVM and the CIL engines can be used to run any programming language you want. They are both turing complete systems, so there is not really anything that will prevent you from targeting any language to run on top of either one of them.

The difference is that the JVM was designed for Java, and Java only.

The CLI originally ran a variation of C++ (they internally called it SMC, or "Smack") and later they created C# and retargeted VB to run on top of it.

But even before this went public, they launched an effort called "Project 7". The goal of this group was to port 7 proprietary languages and 7 research/open source languages to the CIL engine and learn from the exercise what changes were required to make the implementation more efficient. A large number of changes went directly into .NET 1.0, and they allowed the CIL to be a more efficient runtime for running C, C++, Eiffel, Fortran and Cobol than the JVM could. Direct memory manipulation, arbitrary vtable layouts, tail call optimizations all went into .NET 1.0

With .NET 2.0 a new round of languages was tried. The research on ILX and OCaml (mostly using F#) was introduced into the virtual machine, making generic types first-class citizens in the VM, not just entities that were emulated (as they remain to this day in Java). The feedback from Eiffel lead to the introduction of covariance and contravariance in the virtual machine, another feature missing from Java.

The work from Jim Hugunning on IronPython also drove the adoption of new low-level APIs that assisted the runtime in better supporting dynamic languages, all of these features appeared in .NET 2.0 and 3.5.

So certainly, you can target anything into anything else, at the end of the day, everything is running on top of some CPU. The difference is that with .NET you have to jump through less hoops, and the runtime is richer for language developers.

So in Java you can certainly emulate pointers and malloc for building a C compiler. The emulation will tkae the form of "Allocate big array, and emulate pointer operations there". Possible, but not very efficient.

Generics is another area that helped languages like C# get generics that actually make sense, and do not require a PhD to understand. This is an important difference: in Java generics are emulated, in C# they are native to the environment.

That being said, if you like Java, by all means, keep using Java.

Additionally, there are some glorious bindings for Qt called Qyoto now.

The Qyoto bindings power the very pretty Synapse IM client, it is worth taking it out for a spin, because the author has gone the extra mile to make his application good looking and very smooth:

http://eric.extremeboredom.net/2009/03/15/336

That was a research paper on ILX from 2001.

The research work from ILX was folded into .NET 2.0 and is part of ECMA 4th edition.

All of the instructions that you listed are deprecated, they never really made it into .NET, their much improved, polished and battle field tested versions did. And they are the foundation for C#'s generics support and Don Syme's F# compiler, both which run just fine in Mono today.

The current Silverlight 3 preview release supports in addition to the proprietary codecs a pluggable framework for developers that wish to do so to use their own codecs.

As part of the Moonlight effort we now have implemented Vorbis, Theora and ADPCM and have a partial implementation of Dirac almost ready to use.

Our codecs work in both Silverlight 3 and our open source Moonlight implementation.

This means that the specifications can now be used to implement third party implementation and can be used by open source efforts to recreate Flash.

In the Silverlight world that was already possible as Microsoft publishes pretty much all of the specs necessary to implement Silverlight.

Both the Flash plugin from Adobe and the Silverlight plugin from Microsoft are proprietary products. Gnash, Sfwdec and Moonlight are open source implementations of these technology.

I agree that Visual Studio is a very nice tool.

Luckily the code that you produce with Visual Studio will run on Mono (no recompilations necessary) including code that uses ASP.NET MVC. And with the new support for ASP.NET precompiled sites in Mono (available in Mono 2.4) you do not even need to copy the source code to your target server.

Click "Publish" in visual studio, enter the location for your shared directory, and you have a fully working ASP.NET MVC app running on Linux, without leaving Windows.

We are working on various integration points for Visual Studio that will give developers even more: debugging from Visual Studio remote applications deployed on Linux systems and producing packages ready-for-distribution on Linux.

ASP.NET MVC runs on Mono 2.4 out of the box.

Not only does it run, but you can now install a MonoDevelop plugin that will provide all the tooling to get the Linux developer experience to match the Visual Studio experience for MVC development.

It is quite sweet.

Silverlight supports Firefox as well as it supports IE on both Windows and MacOS.

I do not remember the last time I even used IE on Windows to browse the web, and there have been *no* sites that use Silverlight that fail under firefox (we try a lot of them when looking for the "next sample to get working on Moonlight" from http://silverlight.net/Showcase).

If what you were implying though was that Moonlight 2.0 was not ready to run Silverlight 2.0 content, you are right. Moonlight, the open source version of Silverlight is not yet ready to render all of the 2.0 content, but it is very close to it.

Perhaps the Portugal government would like to fund the accelerated development of Moonlight by hiring a few developers to assist the project. That seems like a win-win for everyone involved. Faster Moonlight 2.0 and 3.0 and the warm cozy feeling that they made the world a better place.

Moonlight exists because we were able to put a prototype together in 21 days (you can read about our hack-a-thon here: http://tirania.org/blog/archive/2007/Jun-21.html).

Microsoft has since helped us by providing licensed codecs that can be used by Linux users; Providing us with Silverlight specs for a full open source impleentation (Although 100% of it is available on the web at msdn.microsoft.com) and they provided us with test suites to ensure that Moonlight passes every single Silverlight test suite that Microsoft uses internally.

No two implementations will be 100% compatible. In fact even fixing a bug means that version a and version a.0.0.0.1 with the bug fixed are not "100% compatible", so there is not much point in arguing about 100% compatibility in the first case, it is easy to prove that this will never be the case. But in that regard, no piece of software will ever be (not the kernel, not the browsers, not anything that ever gets bug fixed as a platform).

But we can get very close to the indented behavior as articulated in the test suites "This is what it is supposed to do as far as -we- humans could guarantee". There will certainly be bugs, but we do not have a problem fixing those, and the Microsoft engineers have been very helpful in answering any questions we might have.

It is worth pointing out that the real problem is not really the democrats or the republicans but with the system that has allowed anyone with deep enough pockets to make government do whatever they want.

The NAFTA agreement was not really aimed at helping any of the people in the three participating countries, NAFTA was always designed to help the big corporations reduce their cost of operations. At the same time, NAFTA contained enough provisions that it undid a number of constitutional guarantees and local laws (at least for Mexico it did) and new trade courts ended up having more power than national courts for any trade dispute.

We are getting ready for our first beta of Moonlight 1.0, which will map to Silverlight 1.0, you have a few options to get it running:

(a) Wait until our official Beta launch, and it will contain an easy-to-install plugin. Click install, restart browser, you are done.

(b) You can use it today if you build from our source code, it is published here: http://www.mono-project.com/Moonlight

(c) Repositories like Packman have RPMs that you can install for various distributions that you can install today.

We will be using Microsoft's Media Pack for Linux, which is a licensed version of the media codecs, binary drivers provided by Microsoft. This has the advantage that the media companies that own the patents on codecs have been paid for (MPEG-LA consortium and others).

For those of you that live in a country where software/machine patents are not enforced (media patents are enforced in Europe, contrary to popular lore) or those that just want to stick it to the man, you can build Moonlight with the open source FFMPEG media codecs.

Support for Silverlight 2.0 will ship in preview form in December.