The Future of Managed Languages: C# and Visual Basic
Welcome to this installment of the .NET Nuts & Boltscolumn! The focus of this article will be on sharing itemslearned from various conferences and sources about the nearterm plans for managed languages. Specifically, we willfocus on the plans for C# and Visual Basic. We will examinea shared goal, followed by the trends that are influencingthe next release of both languages.
Traditionally there has been some rivalry between thedifferent Microsoft product teams responsible for the VisualBasic and C# languages. With each new release, one languagegets a cool new toy that leaves the other wondering why theydo not have it. For example, C# introduced generics,nullable types, and auto implemented properties, which tookVB a bit to catch up. VB has had items such as optionalparameters and named arguments that have not existed inC#.
Microsoft has done some re-alignment of the VB and C#product teams to the point now where they report up throughthe same organizational structure. The vision is to have atighter cooperation between the two teams with the benefitto developers that capabilities will show up in bothlanguages pretty much at the same time going forward. Thiswill create a consistency between the two languages and leadto a more consistent experience despite the language. It isnot guaranteed all the existing gaps will be filled betweenthe two languages; it will create a parity of sorts goingforward and comfort knowing things will be introduced withsimilar timing. A result of this parity is that you canassume any topic mentioned in this article will beintroduced in both C# and Visual Basic if it does notalready exist.
Three primary industry trends have influenced the nextreleases of C #and Visual Basic. The trends are declarative,dynamic, and concurrent. We will take a brief look at eachof the trends. Remaining portions of the article willmention or describe functionality being influenced by thesetrends.
Classic programming involves an imperative programmingstyle where one must write very explicit instructions anddetail on how we want something to be done. This can haveoptimization side effects as the compiler has no choice butto execute step-by-step. Declarative programming is moreabout stating an idea, but not having overly specificinstruction. For example, in LINQ you can use the abstract"order by" or "group by" that specifies what you want tohappen, but does not lock the compiler in to having toperform the operations in a specified manner and leaves roomfor optimization.
Concurrent, also known as parallel, programming is aboutwriting code designed to execute multiple steps at the sametime. Moore's law has allowed us to largely ignore writingcode designed to execute in parallel because the processorspeed has continued to increase over time making hardwarethat is more powerful readily available. However, clockspeeds have leveled out now around 2.5 GHz. In order toprovide increased performance, engineers have started addingmore cores to the processor. With more cores available, itmeans to get the next level of performance from yourapplications you would have previously gotten by purchasinga faster processor you will likely need to result to writingcode to execute concurrently. Much like multithreading,writing parallel code is hard and there is no magic answerto make it simple.
Dynamic Language Runtime (DLR)
The argument for and against dynamic languages and staticlanguages has been around since programming languages werefirst created. Each paradigm has its strengths andweaknesses. The Common Language Runtime (CLR) is a commonplatform introduced in Microsoft .NET 1.0 for staticallytyped objects. Since the static paradigm was the onlyparadigm supported, those seeking support for dynamiclanguages were forced to turn elsewhere.
Future Directions for C#
The C# 4.0 language innovations are predominantly focusedon adding support for dynamic languages and closing some ofthe parity with Visual Basic. The planned innovationsinclude the following high-level items:
- Dynamically typed objects
- Optional and named parameters
- Improved COM interoperability