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
Dynamically Typed Objects
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.
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
About the Author
Mark Strawmyer is a Senior Architect of .NET applicationsfor large and mid-size organizations. Mark is a technologyleader with CroweHorwath LLP in Indianapolis, Indiana. He specializes inarchitecture, design and development of Microsoft-basedsolutions. Mark was once again honored to be named aMicrosoft MVP for application development with C#. You canreach Mark at