New technical article on Visual Studio 2010 Language Futures

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?

Perhaps the most exciting new feature in the upcoming .NET 4.0 release is the Dynamic Language Runtime (DLR). In as much as the Common Language Runtime (CLR) provides a common platform for statically typed languages like VB.NET and C#, the Dynamic Language Runtime provides a common platform for dynamically typed languages like JavaScript, Ruby, Python, and even legacy COM components. It represents a major leap forward in language interoperability for the .NET Framework, providing an abstraction of language operations, shared memory space to avoid marshalling data back and forth between processes, a common set of language features like garbage collection, and the plumbing to convert different representations of data from one language to another.

At a high level, you can think of the Dynamic Language Runtime as having three layers (see figure 1 below):

  • .NET Language Integration
  • DLR Core Components
  • Language Binders


    Comments (3)

    1. Jonathan Allen says:

      > If you do opt for this syntax, note that you will not have access to the field which stores the value for the property, which might be an issue if you need to pass the property value by reference into a method.

      That shouldn’t be an issue, the VB compiler will automatically create the temporary variable.

    2. says:

      What’s got LINQ, but doesn’t have a yield keyword and no Action or multiline lambdas? What’s supposed to be an easy to learn language, but supports exception filters when other supposedly more complex languages don’t? The answer, VB.NET. “Co-evolution”