One of the biggest selling features of Visual Studio .Net is in its support for multiple languages. For all intents and purposes, languages are just modules in VS.Net's integrated development environment (IDE). Whether you prefer to code with Microsoft's Visual Basic (VB), Visual C++, or have ventured into the newer C# programming language, the structure of VS.Net's IDE is such that those and more languages can easily call upon all of .Net's classes that in turn do the heavy lifting. For example, I'm using Visual Basic to build a messaging application that's built on the .Net-based programming classes for Outlook. But, if I wanted to, I could do the same thing using C++ or C#. In fact, I can even mix and match. So, if C++ is better for one task, and C# is better for another, no big deal. Code from each language can be compiled into Microsoft's Intermediate Language (MSIL) which in turn runs on .Net's Common Langague Runtime (the CLR). The source language becomes largely irrelevant to the final product. Another advantage to this architecture is the way that same abstraction of language from classes allows programmers in different languages to build for other .Net footprints such as .Net compact -- the framework behind PocketPC.
Not only does this architecture support Microsoft's languages, the modular plug-in nature allows for language modules from other vendors to be dropped in as well. This means that the .Net classes are available to other languages that you or your programmers might be more experienced with, that are better suited to the task, or that a lot legacy code that you're trying to bring up to speed has been already been written in. For example, for tasks that involve a lot of text parsing, perhaps you're preference is to use Perl. ActiveState has you covered with a Visual Perl module for VS.Net that turns your Perl code into MSIL. Or perhaps you have a lot of legacy code written in Cobol. Both MicroFocus and Fujitsu make Cobol modules that drop into VS.Net.
OK. So Microsoft did a good thing in building multi-language support into the Visual Studio IDE thus allowing programmers their choice of language for developing applications to run on its runtime enviroment (RTE) . But what if your preference is to use one of the Java Runtime Environments (JREs) such as J2ME, J2SE, or J2EE as your RTE. While it's doable, Sun hasn't exactly endorsed or promoted the idea of scripting JREs with languages other than Java. As Sun's Tim Bray puts it in a recent blog entry,
"Java has a PR problem; while Microsoft marketed the .NET stuff as multi-language from day one, the fact that Java is a three-legged stool (language, JVM, libraries) kind of gets lost under the enveloping carpet of the one-word name