The Future of Managed Languages: C# and Visual Basic

Introduction

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.

Shared Goal

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.

Trends

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.

Declarative

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.

Dynamic

Dynamic languages are those that have a loose coupling between applications and data services. They involved implicit typing, meta programming, and do not involve compilation. The popularity of dynamic languages such as Python, Ruby, and JavaScript can be seen all across the Internet. To date Microsoft .NET has been about static languages that are robust and offer better scaling. While each has its own strengths and weaknesses, ideally you can borrow from both dynamic and static to create something great.

Concurrent

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.

The Dynamic Language Runtime (DLR) introduced support for dynamic languages on .NET. This creates the possibility of a "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, and call side caching to avoid resolving to the same location more than once. The DLR interfaces with other platform types via binders. There are binders that map dynamic objects to statically typed .NET objects, a JavaScript binder that allows binding directly to JavaScript in Silverlight applications, COM objects, and Python and Ruby. It provides a single programming experience to talking to all of these environments that are not statically typed.

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

The Future of Managed Languages: C# and Visual Basic

Dynamically Typed Objects

It is not uncommon to have to interact with objects differently depending upon the source technology. The following example code depicts the differences in calling a simple calculator that is based on managed code, COM, or JavaScript. You will see the syntax is very different to accomplish 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 will introduce a new dynamic type. The name can be concerning to folks, but rest assured it is actually a static type. Rather than having member selection and type selection at compile time it is deferred until run-time. It behaves similarly to normal static types in other ways. The example code below demonstrates 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 introduced in to C# that gives it more parity with Visual Basic. Optional and named parameters have existed in Visual Basic for as long as I can remember and will now be in C# as well.

  // 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 the introduction of optional and named parameters provides a better 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 VB 10 focus around the aforementioned parity. The list contains but 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.

Summary

You have learned about a shared goal between C# and Visual Basic as well as some of the industry trends that are influencing the next release of the two languages. We looked specifically at some of the items planned for both languages. I hope that it provided you high-level insight as to what is coming.

Future Columns

The topic of the next column is likely to be a deeper dive in to one of the topics on the next release of the .NET Framework. If you have something in particular that you would like to see explained here you could reach me at mark .strawmyer@crowehorwath.com.

About the Author

Mark Strawmyer is a Senior Architect of .NET applications for large and mid-size organizations. Mark is a technology leader with Crowe Horwath LLP in Indianapolis, Indiana. He specializes in architecture, design and development of Microsoft-based solutions. Mark was once again honored to be named a Microsoft MVP for application development with C#. You can reach Mark at mark .strawmyer@crowehorwath.com.



About the Author

Mark Strawmyer

Mark Strawmyer is a Senior Architect of .NET applications for large and mid-size organizations. He specializes in architecture, design and development of Microsoft-based solutions. Mark was honored to be named a Microsoft MVP for application development with C# for the fifth year in a row. You can reach Mark at mark.strawmyer@crowehorwath.com.

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: September 17, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Another day, another end-of-support deadline. You've heard enough about the hazards of not migrating to Windows Server 2008 or 2012. What you may not know is that there's plenty in it for you and your business, like increased automation and performance, time-saving technical features, and a lower total cost of ownership. Check out this upcoming eSeminar and join Rich Holmes, Pomeroy's practice director of virtualization, as he discusses the …

  • Java developers know that testing code changes can be a huge pain, and waiting for an application to redeploy after a code fix can take an eternity. Wouldn't it be great if you could see your code changes immediately, fine-tune, debug, explore and deploy code without waiting for ages? In this white paper, find out how that's possible with a Java plugin that drastically changes the way you develop, test and run Java applications. Discover the advantages of this plugin, and the changes you can expect to see …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds