July 22, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

The Future of Managed Languages: C# and Visual Basic

  • August 25, 2009
  • By Mark Strawmyer
  • Send Email »
  • More Articles »

Introduction

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.

Trends

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.

Declarative

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

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

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




Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel