I commissioned an article on language futures in Visual Studio 2010, to cover off C#, Visual Basic, DLR, F# and Parallel Programming. I think the author did a superb job on it. Well done Damon.
The Future of .NET Languages
At the 2008 Microsoft Professional Developer’s Conference, a number of striking changes were outlined for .NET programming languages. In addition to answering many .NET developer concerns, the changes should make developers more productive and allow them to more easily create richer applications.
by Damon Armstrong
December 10, 2008
At this year’s Professional Developers Conference (PDC 2008), Microsoft® was quite forthcoming with specifics about the future for developers on the Microsoft .NET® platform. In this article, we will take a quick look at some of the upcoming features in the .NET 4.0 Framework, the new Microsoft F#® language, and discuss the long-term vision Microsoft has for the .NET Platform in the years to come.
Co-Evolution for VB.NET and C#
One of the most prominent messages coming from Microsoft right now is geared towards Microsoft Visual Basic® .NET developers. VB.NET and Microsoft Visual C#® are both built on top of the Common Language Runtime (CLR), which means they both compile down into the same Common Intermediate Language (CIL). Since they both compile down to the same code, there should be no intrinsic benefit of one language over another. However, both languages are maintained by separate teams at Microsoft, and over the years this separation has led to a variety of language-specific features in both C# and VB.NET as the teams focus on different areas with their respective products. Many VB.NET developers feel that the most exciting new features appear in C# first and are only later introduced into VB.NET. Naturally, this has generated a bit of animosity in the VB.NET community.
Co-evolution is a promise from Microsoft that recognises VB.NET and C# as equally important languages, and guarantees that as new language features evolve, those features will be incorporated into both languages simultaneously. No longer will you need to second guess your decision to go with a particular language for want of a particular feature, and the debate between which language is “better” will be reduced back down to syntactic preference. And while C# developers will probably have a lingering superiority complex with which VB.NET developers will have to contend, all VB.NET developers need to do is remind the C# devs that it’s all the same under the covers.
Introducing the Dynamic Language Runtime
Microsoft is acutely aware that the .NET Framework is not the only choice for building applications. All you have to do is take a quick glance around the development sphere and you’ll find a number of language options, and that number is only expected to rise as domain-specific languages emerge. People are spending time and energy writing useful components in these languages, so the question is, how can you use a component written in another language without having to rewrite it in .NET?
At a high level, you can think of the Dynamic Language Runtime as having three layers (see figure 1 below):