In a post entitled .NET Reality Check Jon Udell writes

3. Programming language neutrality. Here's a statement, from an early Jeff Richter article about .NET, that provoked oohs and ahhs at the time: "It is possible to create a class in C++ that derives from a class implemented in Visual Basic." Well, does anybody do this now? Is it useful? Meanwhile, the dynamic language support we were going to get, for the likes of Perl and Python, hasn't arrived. Why not?

The primary benefit of programming language neutrality is that library designers can build a library in one language and developers using other languages can use them without having to worry about language differences. The biggest example of this is the .NET Framework's Base Class Library, it is mainly written in C# but this doesn't stop VB.NET developers from writing .NET applications, implementing interfaces or subclassing types from the various System.* namespaces.

Examples closer to home for me are in RSS Bandit which depends on a couple of third party libraries such as Chris Lovett's SgmlReader and Tim Dawson's SandBar. I've personally never had to worry about what language they were written in nor do I care. All I need to know is that they are targetted at the .NET Framework.

On the other hand, when the .NET Framework was first being hyped there were a lot of over enthusiastic evangelists and marketters who tried to sell the programming language neutrality as something that would also allow you to have developers working on a single project use different languages. Although theoretically possible, that always seemed like an idea that would be unwise to implement in practice. I can imagine how problematic it would be if Torsten wrote managed C++ code and I wrote VB.NET code for the different parts of RSS Bandit we worked on. Fixing each others bugs would be a painful experience.