Computer languages are numerous. Traditionally, new languages have been created to respond to new needs, such as resolving scientific problems, making calculations for research, or meeting strong needs in terms of application reliability and security. The result is that existing languages are heterogeneous: some are procedural, others object-oriented, some authorize use of optional parameters or a variable number of parameters, some authorize operator overload, others do not, and so it goes on.
For a language to be eligible for the range of languages supported by the .NET platform, it must provide a set of possibilities and constructions listed in an agreement called the Common Language Specification, or CLS. To add a language to .NET, all that is required in theory is for it to meet the requirements of the CLS, and for someone to develop a compiler from this language into MSIL.
This seems fairly innocuous at first glance, but the restrictions imposed by CLS-compliance on the different .NET languages mean that, for example, Visual Basic .NET ends up becoming a new language which retains little more than the syntax of Visual Basic 6.
The fact that all the .NET languages are compiled in the form of an intermediate code also means that a class written in a language may be derived in another language, and it is possible to instantiate in one language an object of a class written in another language.
Today, if you want to create a COM+ object, you generally have the choice between VB6 and Visual C++. But VB6 does not give access to all possibilities, and for certain requirements, you are restricted to VC++. With .NET, all languages will offer the same possibilities and generally offer the same performance levels, which means you can choose between VB.NET and C# depending on your programming habits and preferences, and are no longer restricted by implementation constraints.
At this point, you may be wondering how this can all be possible. Magic? Not really. In our opinion, there is no magic wand being waved here. To give a more even view of the multi-language aspect of .NET, we would prefer to say that .NET only supports one language, MSIL. Although Microsoft does let you choose whether to write this MSIL code using Visual Basic syntax, or C++ syntax, or Eiffel…
To put it frankly, in order to be able to provide the same services from languages as remote as Cobol or C#, you have to make sure these languages have a common denominator which complies with the demands of .NET. This means that the .NET version of Cobol has had to receive so many new concepts and additions that it has practically nothing left in common with the original Cobol. This applies just as much to the other languages offered in .NET, such as C++, VB, Perl or Smalltalk.
So what we need to understand is that when Microsoft announces the availability of 27 languages, we should interpret that as meaning there are 27 different syntaxes.
The most symptomatic example concerns Java. It is one of the intended .NET languages, thanks to Rational, who are currently working on a Java to MSIL compiler. But what kind of Java are we talking about? It is a Java which runs as MSIL code, not byte-code. This Java does not benefit from the traditional APIs offered by the J2EE platform, such as JMS, RMI, JDBC, JSP. This is a Java in which EJBs are replaced by .NET's distributed object model. The label says Java, the syntax says Java… but Java it ain't!
Of course, the case of Java is a bit of an exception. Indeed, Java specialists see .NET overall as a rather pale copy of Java itself, and consider it to be proof of Microsoft's successive attempts to undermine Java's future. Relations between Sun and Microsoft have been peppered with disputes and lawsuits in recent years. It was out of the question that Microsoft would participate in the construction of Java by offering total support for the language in its new .NET platform.
From our perspective, the support for Java in .NET is, as it stands, totally unusable if one intends to maintain a degree of compatibility with Sun's J2EE platform. We believe that its only justification is that it reinforces Microsoft's campaign to seduce developers. Microsoft's strategy is to win over developers in order to benefit from their prescriptive powers, with the aim of eventually imposing .NET on a wide scale.
Similarly, Microsoft is cleverly entertaining certain rumors, such as the recurring whispers predicting the eventual availability of .NET on Unix systems, even Linux. Linux is increasingly popular among developers, and is becoming a potential alternative to Windows NT as far as server architectures are concerned. By keeping details hazy around the issue of Linux support for .NET, Microsoft can win over fans of the free operating system.