Iris Classon
Iris Classon - In Love with Code

‘Stupid’ Question 33: Why was the DLR and Dynamic keyword introduced in Net?

[To celebrate my first year of programming I will ask a ‘stupid’ questions daily on my blog for a year, to make sure I learn at least 365 new things during my second year as a developer]

From Wiki: “Plastic dynamism”, a term used by the Italian futurist art movement to describe a concept pertaining to an object’s motion, both intrinsic and relative to its environment. Painting by Umberto Boccioni

I went to a user group meeting yesterday with Swenug and listened to Filip Ekberg talk about Roslyn, reflection and Dynamic. I’ve been using reflection and dynamic, the latter one more the last few months as we worked with SimpleData (“A light-weight, dynamic data access component for C# 4.0”). First time I ever looked at dynamic was two months into programming when I missed the last buss home and decided to watch some random Pluralsight tutorial while waiting. What I remember was thinking, ‘cool stuff, but doesn’t fit in with the language?’. I didn’t know anything about dynamic languages at the time, and I forgot that thought until yesterday, when I asked this at the UG. I got the reply ‘Ruby envy’ – and although a funny comment, I would still like to know, why was the dynamic keyword and the DLR added to .Net?

Lucky me I found a great article on MSDN by Alexandra Rusina that answered my question:

DLR was introduced to allow static typed languages, such as C# to work with languages such as ruby (hence the Ruby-envy comment) and python, and to add dynamic behavior to the language.

I get the first one, interoperability (you will find many examples with Microsoft Office), but it is the second reason that I’m most curious about. Do we need dynamic behavior in a static language and in your opinion – does it fit in?


Leave a comment (via email)
8/29/2012 3:31:12 PM
Someone already mentioned COM for the dynamic keyword, so I'll skip that. The DLR side of the question though, part of the reason it was being added was because it was never really that easy to get dynamic languages to use the CLR effectively. So part of the reason for the DLR was to simplify that a bit (think ironpython, ironruby, etc). So the joke about ruby envy wasn't too far off on the DLR side of the question. Or atleast that's how they made it sound when it came out. 
Jeff Yates
8/29/2012 8:30:10 AM
I was under the impression that it was added predominantly to simplify COM interop.

Some sources: 
Mikael Eliasson
8/29/2012 8:37:29 AM
Yes and no! 

Most of the time we want to stay with static typing but there are always things out of our control. Like parsing XML or calling into COM where we previously had to resort to magic strings or clunky APIs that wouldn't provide any typesafety anyway. 

See this example for how COM becomes simpler:

Then there are things like the ViewBag in mvc which is much nicer to use now that we have dynamic even though I would personally strongly argue for using typed views instead. 

So we don't really need it and we shouldn't abuse it. Use it to make situations where we have no type safety anyway more developer friendly. 
Iris Classon
8/29/2012 8:39:01 AM
Reply to: Jeff Yates
That seems to be one of the main use-scenarios- and goes under reason one - interoperability

An interesting article: 
Iris Classon
8/29/2012 8:42:56 AM
Reply to: Jeff Yates
LOL we edited our comments at the same time and added the same link :D 
James Curran
8/29/2012 10:00:15 AM
"dynamic" objects are, for the most part, just a syntax around a Dictionary.  We've had those since .NET v1.0 (albeit in a non-generic form), so one could argue that they are necessary.   But, as with many things in programming, the slick syntax masks a lot of complexity, which you might want to be aware when designing & coding. 
James Tryand
8/31/2012 7:23:15 AM
+1 Mikael Eliasson, +1 James
I find dynamic a bit of a mixed blessing. the following is my use of them for day to day use.

performance & simplicity for co/contravariance can also be a reasonable use. 
using delegates to convert between types can be very performant and more flexible than using reflection, but that comes at the cost of the code becoming more complex to maintain and less clear to read.

using dynamic keyword to help, while it's not as performant as the delegate based techniques, it is still reasonable in performance and certainly clearer. 

there is the obvious issue though that this should be guarded well as using this does weaken the typing with a pinch point at its use, so should be used carefully and sparingly in order to maintain the benefit of the typing from the compiler.

if you make use of code contracts, then there are obvious issues in that they are mutally exclusive technologies, and so would loose the compiler benefits there. There are assumptions that can be applied to the code contracts, and if you've maintained your code appropriately these restrictions needn't be too much of a problem.

they are not escaping the type system (in the way that nulls can be - but dont get me started on the lack of a BCL type for Unit ;-) ), they are just loosening it; too loose and you stop the compiler being able to help you. I presume we are all in agreement that that's not good, and on the whole is seen as sloppy coding. 

Last modified on 2012-08-28