At Microsoft's recent BUILD conference, technical fellow and C# creator Anders Hejlsberg presented a session on the future of C# and Visual Basic. Visual Basic? There were few VB developers evident at BUILD and it seems to be in decline among professionals. Nevertheless, Microsoft is keeping the two in parity: read on for why the difference between them is becoming smaller.
The Hejlsberg talk was not all new. The two big features he presented – asynchrony and compiler as a service – have both been presented before. That said, the asynchronous features in C# 5.0 are more significant now that Microsoft has shown its new Windows Runtime (WinRT), with which it hopes to compete in the tablet market. Around 15 per cent of the APIs in WinRT are asynchronous, with no alternative provided. The idea is to force developers to build apps with responsive user interfaces.
Concurrent programming in C# was in the language from version 1.0. The effort since then has been to make it more efficient and easier to code, especially since mistakes can introduce subtle bugs. C# 4.0 introduced the Task Parallel Library, an abstraction that simplifies coding to some extent, but the new async features are even easier, especially when used with existing APIs like those in WinRT.
Hejlsberg: "It is all about orchestrating execution"
In a nutshell, C# 4.0 will rewrite your code at compile-time to make it asynchronous. Developers can code almost as if it were synchronous, though they still need to pay attention to what is happening under the covers.
There are two new keywords: async and await. If you declare a function or method to be async, this tells the compiler to rewrite it for you. This does not automatically make it asynchronous, but only if you also use await in the body of the function.
The await keyword is used before a function call. The function then exits immediately, so the user can continue to interact with the user interface. If you wrote further code in that function, below the await statement, then this gets executed later, after the awaited function completes. C# preserves state such as the value of variables.
You can already get equivalent functionality in C# 4.0, using the ContinueWith method of a Task. The new approach is more natural though, especially as you can use multiple await statements in the same method. "It is all about orchestrating execution," said Hejlsberg.
By contrast, the compiler as a service project – codenamed Roslyn – is not just syntactic sugar. Microsoft is creating an API for the C# and VB compilers that will let you use them in your runtime code. In fact, it is building new compilers for C# and VB in managed code that both use and create the APIs. This will enable a number of new features, including evaluating C# expressions at runtime, more powerful refactoring and navigation tools, and a C# interactive prompt in Visual Studio.
Evaluating code at runtime was already possible, using a feature called Reflection, but Roslyn is both far more extensive and easier to use. Hejlsberg showed a ScriptEngine object that lets you use C# as a scripting language within your applications. You could use this to enable users of your application to run macros or extend it with their own user-defined functions.
"I'm not going to say when we ship this," said Hejlsberg, implying that it may not be part of Visual Studio 11, which will ship around the time of Windows 8. A Community Tech Preview (CTP) is promised for the middle of this month.
Developers may notice Roslyn more by what it enables, than by using the features directly. Tools in Visual Studio that generate or modify code will be more capable, because they can get a deeper understanding of what your code does by compiling it on the fly and inspecting the syntax tree returned by the compiler.
By way of example, Hejlsberg showed how a tool built with Roslyn can convert C# to VB and vice versa. It will be ideal for VB developers moving to C#, who can simply paste their old code; unlike those old Visual Basic 6 porting tools, this one will most likely work fine.
Maybe those skeptics who said that all .NET languages were really C# in disguise had a point. ®