The Future of Managed Languages: C# and Visual Basic


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

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.


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


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 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


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

More by Author

Must Read