Welcome to this installment of the .NET Nuts & Bolts column! The focus of this article will be on sharing items learned from various conferences and sources about the near term plans for managed languages. Specifically, we will focus on the plans for C# and Visual Basic. We will examine a shared goal, followed by the trends that are influencing the next release of both languages.
Traditionally there has been some rivalry between the different Microsoft product teams responsible for the Visual Basic and C# languages. With each new release, one language gets a cool new toy that leaves the other wondering why they do not have it. For example, C# introduced generics, nullable types, and auto implemented properties, which took VB a bit to catch up. VB has had items such as optional parameters and named arguments that have not existed in C#.
Microsoft has done some re-alignment of the VB and C# product teams to the point now where they report up through the same organizational structure. The vision is to have a tighter cooperation between the two teams with the benefit to developers that capabilities will show up in both languages pretty much at the same time going forward. This will create a consistency between the two languages and lead to a more consistent experience despite the language. It is not guaranteed all the existing gaps will be filled between the two languages; it will create a parity of sorts going forward and comfort knowing things will be introduced with similar timing. A result of this parity is that you can assume any topic mentioned in this article will be introduced in both C# and Visual Basic if it does not already exist.
Three primary industry trends have influenced the next releases of C #and Visual Basic. The trends are declarative, dynamic, and concurrent. We will take a brief look at each of the trends. Remaining portions of the article will mention or describe functionality being influenced by these trends.
Classic programming involves an imperative programming style where one must write very explicit instructions and detail on how we want something to be done. This can have optimization side effects as the compiler has no choice but to execute step-by-step. Declarative programming is more about stating an idea, but not having overly specific instruction. For example, in LINQ you can use the abstract "order by" or "group by" that specifies what you want to happen, but does not lock the compiler in to having to perform the operations in a specified manner and leaves room for optimization.
Concurrent, also known as parallel, programming is about writing code designed to execute multiple steps at the same time. Moore's law has allowed us to largely ignore writing code designed to execute in parallel because the processor speed has continued to increase over time making hardware that is more powerful readily available. However, clock speeds have leveled out now around 2.5 GHz. In order to provide increased performance, engineers have started adding more cores to the processor. With more cores available, it means to get the next level of performance from your applications you would have previously gotten by purchasing a faster processor you will likely need to result to writing code to execute concurrently. Much like multithreading, writing parallel code is hard and there is no magic answer to make it simple.
Dynamic Language Runtime (DLR)
The argument for and against dynamic languages and static languages has been around since programming languages were first created. Each paradigm has its strengths and weaknesses. The Common Language Runtime (CLR) is a common platform introduced in Microsoft .NET 1.0 for statically typed objects. Since the static paradigm was the only paradigm supported, those seeking support for dynamic languages were forced to turn elsewhere.
Future Directions for C#
The C# 4.0 language innovations are predominantly focused on adding support for dynamic languages and closing some of the parity with Visual Basic. The planned innovations include the following high-level items:
- Dynamically typed objects
- Optional and named parameters
- Improved COM interoperability