Like many developers, I’ve started the process of getting acquainted with beta 1 of Visual Studio .NET 2005, along with the new versions of both C# and Visual Basic .NET. One thing has become increasingly apparent – Microsoft is effectively abandoning the Common Language Specification (CLS).
If you think back a couple of years when .NET was first announced, the CLS was one of the lynchpins of the .NET message. The idea that every .NET compatible language would be able to work seamlessly with any other .NET language was one of the key innovations of .NET. This meant you could create components in any language, and easily use them from any other – a vast improvement over the previous generation where mixed language development required great care to match calling conventions, parameter count and type, and responsibility for reference counting and memory management.
There is no doubt that .NET is a huge improvement over previous approaches. As a component developer, and someone who strongly believes in software reuse and component based software development, the CLS was gospel. I believed that every assembly should always be CLS compliant (even private code, in the hope that one day it might be refactored into components). Visual Basic .NET 2002-3 produces CLS compliant code by default. C# does not, though it’s not hard to maintain CLS compliance, and the compiler can check for it if you wish.
With Visual Studio 2005 it seems clear that Microsoft has effectively abandoned the CLS in favor of a new standard: specifically – the set of language constructs supported by Visual Basic .NET and C#.
Want proof? Visual Basic .NET 2005 no longer creates CLS compliant code by default.
And you know what? Microsoft made the right decision in this case. Leaving these features out of VB .NET would have crippled the language (both in perception and in reality, though mostly the former – a subject I’ll return to later).
The three major non-CLS compliant features I’ve seen so far are generics, unsigned variables and different access levels for property procedures. All of these are extraordinarily useful features for VB .NET. All will make it easier for VB .NET and C# assemblies to work together.
What does this mean to other language vendors? Can they leave out these features with the argument that they are not necessary because they are not CLS compliant? Of course not – how can you be less than 100% compatible with the two major .NET languages? In effect, VB .NET and C# will define the new de facto standard.
The idea of a common language specification is a good one, and the truth is – they are so close that it’s hard to see this as a big deal. But language interoperability is important – especially if we are ever going to convince developers to truly adopt component-based development. Both VB .NET and C# should produce CLS compliant code by default and require an explicit developer choice to turn it off (just as systems should be secure by default – same concept). But I’m not suggesting they change the default attributes for VB .NET and C# projects. Rather, Microsoft should update the CLS to match the new de facto standard and make that the default setting for VB .NET and C#. This will help vendors of other components and the folks developing Mono to have a clear common guideline to work with, and in the long term ensure that the interoperability promised with .NET does not devolve into an illusion.
Related Articles:
How Microsoft Lost the API War by Joel Spolsky is essential reading to every Windows software developer. Check out his new book.
RSS feeds for sites referred to in this item:
I think we’ll see the languages and CLS spec sync back up in the Orcas timeframe.
Please correct me if I’m wrong, but I thought that the CLS was a part of the ECMA standard.
This would mean that if MS wants to update the CLS, it has to go through the ECMA standards process.