Welcome to this installment of the .NET Nuts & Bolts
column! The focus of this article will be on the dynamic
language support that will be released as a part of the
upcoming 4.0 version of the .NET Framework. In order to run
the examples contained within this article you’ll need to
use an early preview such as a beta or CTP of the .NET
Framework 4.0 release.
Note: In order to run the examples contained within
this article you’ll need to use an early preview such as a
beta or CTP of the .NET Framework 4.0 release.
Dynamic Language Runtime (DLR)
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
Internet. To date Microsoft .NET has been about static
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) introduces 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
applications, COM objects, and Python and Ruby. It provides
a single programming experience for talking to all of these
environments that are not statically typed.
Figure 1 – Dynamic Language Runtime