The Future of Managed Languages: C# and Visual Basic

Tuesday Aug 25th 2009 by Mark Strawmyer

In this installment of the .NET Nuts & Bolts column we'll be discussing three industry trends that are influencing the next releases of 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.

Shared Goal

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.


Dynamic languages are those that have a loose couplingbetween applications and data services. They involvedimplicit typing, meta programming, and do not involvecompilation. The popularity of dynamic languages such asPython, Ruby, and JavaScript can be seen all across theInternet. To date Microsoft .NET has been about staticlanguages that are robust and offer better scaling. Whileeach has its own strengths and weaknesses, ideally you canborrow from both dynamic and static to create somethinggreat.


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.

The Dynamic Language Runtime (DLR) introduced support fordynamic languages on .NET. This creates the possibility ofa "best of" scenario where you can use from both paradigms.The core infrastructure of the DLR includes expression trees(such as LINQ), dynamic dispatch to different binders, andcall side caching to avoid resolving to the same locationmore than once. The DLR interfaces with other platform typesvia binders. There are binders that map dynamic objects tostatically typed .NET objects, a JavaScript binder thatallows binding directly to JavaScript in Silverlightapplications, COM objects, and Python and Ruby. It providesa single programming experience to talking to all of theseenvironments that are not statically typed.

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

Dynamically Typed Objects

It is not uncommon to have to interact with objectsdifferently depending upon the source technology. Thefollowing example code depicts the differences in calling asimple calculator that is based on managed code, COM, orJavaScript. You will see the syntax is very different toaccomplish the same thing.

  // Managed code  Calculator calc = GetCalculator();  int sum = calc.Add(10, 20);    // COM Interop  object calc = GetCalculator();  Type calcType = calc.GetType();  object res = calcType.InvokeMember("Add",      BindingFlags.InvokeMethod, null,      new object[] { 10, 20 });  int sum = Convert.ToInt32(res);    // JavaScript  ScriptObject calc = GetCalculator();  object res = calc.Invoke("Add", 10, 20);  int sum = Convert.ToInt32(res);

The next release of both C# and Visual Basic willintroduce a new dynamic type. The name can be concerning tofolks, but rest assured it is actually a static type. Ratherthan having member selection and type selection at compiletime it is deferred until run-time. It behaves similarly tonormal static types in other ways. The example code belowdemonstrates the use of the dynamic type.

  // Method chosen at compile time  double x = 1.75;  double y = Math.Abs(x);     // Method double Abs(double x) chosen at run-time  dynamic x = 1.75;  dynamic y = Math.Abs(x);     // Method int Abs(int x) chosen at run-time  dynamic x = 2;  dynamic y = Math.Abs(x); 

Optional and Named Parameters

Optional and named parameters are items being introducedin to C# that gives it more parity with Visual Basic.Optional and named parameters have existed in Visual Basicfor as long as I can remember and will now be in C# aswell.

  // Optional parameters have default values  public StreamReader OpenTextFile(      string path,      Encoding encoding = null,      bool detectEncoding = true,      int bufferSize = 1024);     // Leaving off parameters in the call  OpenTextFile("foo.txt", Encoding.UTF8);    // Named parameters can appear in any order  OpenTextFile(      bufferSize: 4096,      path: "foo.txt",      detectEncoding: false);

Improved COM Interoperability

The object binders introduced with the DLR along with theintroduction of optional and named parameters provides abetter COM interoperability experience overall.

  // Original code  object fileName = "Test.docx";  object missing  = System.Reflection.Missing.Value;    doc.SaveAs(ref fileName,      ref missing, ref missing, ref missing,      ref missing, ref missing, ref missing,      ref missing, ref missing, ref missing,      ref missing, ref missing, ref missing,      ref missing, ref missing, ref missing);    // Replacement code now possible  doc.SaveAs("Test.docx");

Future Directions for Visual Basic

Much of the language innovations currently planned for VB10 focus around the aforementioned parity. The list containsbut is not limited to the following:

  • Generate from use - type an object name and allow the IDE to generate a stub object or method.
  • Auto-implemented properties - create a public property that is not backed by a full accessor method or field and the compiler will generate one.
  • List initializers - ability to create an initialize a list all within a single statement the same as what C# supports.
  • Implicit line continuation - do not have to use the annoying "_" in order to continue a line to the next line!
  • Parallel extensions - extensions added to support parallel programming.
  • No primary interop assembly - ability to embed referenced types directly within an assembly.


You have learned about a shared goal between C# andVisual Basic as well as some of the industry trends that areinfluencing the next release of the two languages. We lookedspecifically at some of the items planned for bothlanguages. I hope that it provided you high-level insight asto what is coming.

Future Columns

The topic of the next column is likely to be a deeperdive in to one of the topics on the next release of the .NETFramework. If you have something in particular that youwould like to see explained here you could reach me at