The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

DLR vs. CLR?

Uhm, whats the difference?  And why the need for a DLR, and not just compile the scripting languages to the CLR Bytecode language (i'm not sure the name for it).

Anyone care to share their knowledge on this topic?
Vincent Send private email
Tuesday, May 01, 2007
As I understand it, you only need to use the DLR if you are writing a dynamic language compiler.  If you are using a dynamic language that uses the DLR you will probably need it, but you don't really need to worry about what is in it.
Daniel Plaisted Send private email
Tuesday, May 01, 2007
The CLR doesn't have the right kinds of opcodes for implementing dynamic languages.

For example, the CLR has an instruction called InvokeVirtual, which is used for calling a virtual method on a class or interface instance. When the classloader reads a .NET assembly, it verifies that the method targets for InvokeVirtual are all valid methods for the classes/interfaces where they're used.

However, in a duck-typed language like Ruby, where you can call methods willy-nilly (even if the class doesn't implement  a method with that name), the semantics of InvokeVirtual don't quite cut it.

So the DLR includes a new opcode called InvokeDynamic, which supports method invocations on unknown on non-existent methods.

Additionally, dynamic languages often allow classes to be dynamically redefined by program logic (which is disallowed by both the CLR and the JVM).

That's the kind of stuff dynamic languages need in their runtime environment (not to mention type inference, and other dynamic-typic goodies).
BenjiSmith Send private email
Tuesday, May 01, 2007
From the beginning, Microsoft's .NET framework was designed to support a broad range of different programming languages on a Common Language Runtime (CLR).  The CLR provides shared services to these languages ranging from a world-class GC and JIT to a sandboxed security model to tools integration for debugging and profiling.  Sharing these features has two huge benefits for languages on the CLR.  First, it's easier to implement a language because lots of difficult engineering work is already done for you.  Second, and more importantly, these languages can seamlessly work together and share libraries and frameworks so that each language can build on the work of the others.

The CLR has good support for dynamic languages today.  IronPython-1.0 demonstrates this.  The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better.  It adds to the platform a set of services designed explicitly for the needs of dynamic languages.  These include a shared dynamic type system, standard hosting model and support to make it easy to generate fast dynamic code.  With these additional features it becomes dramatically easier to build high-quality dynamic language implementations on .NET.  More importantly, these features enable all of the dynamic languages which use the DLR to freely share code with other dynamic languages as well as with the existing powerful static languages on the platform such as VB.NET and C#.

Tuesday, May 01, 2007
David Lee Roth, any day.
Wednesday, May 02, 2007
Benji....congratulations on your new job in Boston!

I'm sure you will excel at whatever project/job you decide to pursue.....
Brice Richard Send private email
Wednesday, May 02, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz