The Future of .NET Languages?

I came across this article and really enjoyed it, thats why I have to share it with you. Written by Damon Armstrong this article gives a bit of light what is next in .NET field.

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.

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):

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

image001 The Future of .NET Languages?

The first layer, .NET Language Integration, simply represents the need for .NET languages to have a notion of what the DLR is and how to use it. For the most part, you won’t even notice this aspect of the DLR because most of the .NET languages had a natural integration point. IronRuby and IronPython are both dynamically typed languages, so the DLR fit right in. VB.NET has always supported the notion of late binding on the Object type, so the DLR incorporated nicely into late binding resolution. C#, however, has no notion of late binding and needed an additional static type for dynamic language support. It’s called the dynamic type, and we’ll talk about it in more detail a bit later.

Language Binders, which make up the third layer, are language-specific implementations of certain operations the Dynamic Language Runtime needs to understand about each language that wishes to participate in the DLR.

New Language Features in .NET 4.0
– Dynamic Lookup (New to C#)
– Named and Optional Parameters (New to C#)
– Anonymous Method Support (New to VB.NET)
– Co-variance and Contra-variance (New to C# and VB.NET)
– Dynamic Import (New to C#)
– Omitting Ref Parameters (New to C#)
– Compiling without Primary Interop Assemblies (New to C# and VB.NET)
– Implicit Line Continuation (New to VB.NET)
– Simplified Property Syntax (New to VB.NET)
– Array Type Inference and Jagged Arrays (New to VB.NET)
– From Keyword (New to VB.NET)

Functional Programming with F#

F# is a succinct, high performance, type-inferred, functional language built on top of the .NET Framework. Microsoft has a solid base of imperative programming languages with VB.NET and C#, but there is a trend in computing that tends to be moving towards a more declarative style of programming. What’s the difference? In an imperative language you write code that tells the compiler exactly how to do something, whereas in a declarative language you write code that says what you want to do, but leave the “how” part up to the compiler. Now, the ultimate declarative language would allow you to write something like “Morph the screen into something cool” and then compile your thoughts into a wicked screen saver or some such, but we’re not there just yet. F# offers developers the opportunity to explore declarative concepts and offer a useful language to customers whose thinking is geared more towards functional development.

Read the whole of this article from the source.

Leave a Reply

Your email address will not be published. Required fields are marked *