A future for Dynamic Feature Runtime in context of c#?

Question

So c# had evolved as staticly typed language and does a more than a perfect job in holding the niche in developing the Line of Business Applications with .net framework.

Now, clearly, in recent past, microsoft has started making leaps towards other fundamental paradigms for which c# and .net never really claimed to be the tool up untill the recent past.

One of these is the DLR

Ok language divercity - great, I am thinking, only now it looks like I have to change the way I am thinking when I write my business entities with classes if I want to take advantage of the feature...Which is cool, and I am all of learning the new. But before I do I have some questions for the respected community in that regards. Now for the sakes of clarification, I am more so interested in the application of the DLR alongside CLR.

So we begin:

1. To your opinion, is DLR a viable feature that desrves to be looked at from the enterprise commercial software development standpoint? Meaning, does c# really need that as a feature to continue to do what it's doing or would it make more sense to switch to a standart dynamicly typed language at that point?

2. Where the combination of developing and writing code with CLR and DLR shine in terms of business applicability? Concrete examples would be the most valued to me.

3. Benefits.

Now the msdn says this:

Provides Future Benefits of the DLR and .NET Framework Languages implemented by using the DLR can benefit from future DLR and .NET Framework improvements. For example, if the .NET Framework releases a new version that has an improved garbage collector or faster assembly loading time, languages implemented by using the DLR immediately get the same benefit. If the DLR adds optimizations such as better compilation, the performance also improves for all languages implemented by using the DLR.

Well great, but how exactly? And won't I get the same if I just upgrade my framework anyways? Why do I need to write in DLR for that?

1. Can you post code samples to showcase that DLR can do a better jon than regular c#?

2. Is it worth to learn it to be a marketable .net engineer, or is it more or less an isoteric feature to just say: "Oh we are better than Ruby, bc we can do it too plus more"?

3. What are the overhead of combining those 2 or just using the DLR by itself in app. developing?

4. Can DLR be used with f#?

Regards.

Answer 1

It might be worth clarifying that the DLR is an API layered on top of the CLR to lower the bar for implementing dynamic typing language features. You can use it end-to-end as IronPython, IronRuby, Clojure, and other languages do to implement your language. You can use it piece-meal like C# or VB to just get dynamic call site caching (search for inline polymorphic caching for general info on the concepts). So, C# adding the 'dynamic' keyword, and it uses the DLR's CallSites, binders, DynamicMetaObjects, etc., to implement this language feature.

Yes, the DLR is a viable feature and makes sense for C#. C# was behind VB for COM interop, untyped data sources (DB, XML, etc.), and for lighter weight syntax behind web pages (e.g., button.text = "yo"). When I love a language, find it generally useful, or have tuned my prowess in it, I like to use that language as much as possible. I don't want to have to cobble together and create maintenance overhead in my solution by using multiple languages unless I really need to do that. C#'s 'dynamic' lets me do things I could already do in C# in a much easier and tastier way, and it certainly means I don't have to resort to a purely dynamic or optionally explicitly typed language for easier to write code in many more situations now.

Developing code with the DLR shines if you are trying to add dynamic type features to a language or big, rich system. As is often quoted, "any sufficiently complicated … program contains an ad hoc … implementation of … Lisp." If you're finding you need some dynamically typed access to data or objects, with some computation of what an operation means given some inputs and want to cache that action for subsequent similar computations at that location in the program, the DLR helps you do that in a lower cost way. The thing is, you may not even need to use the DLR at this level since C# has introduced 'dynamic' for you. However, you may want to implement IDynamicMetaObjectProvider on some objects representing your data sources so that they can participate in the binding operations that C#'s dynamic dispatch callsites perform. An example of this would be if XmlElement implemented IDMOP so that you could write something like: dynamic x = source.GetXmlElement(…); … x.Customers[i].Address.City == "Erie" …

The benefits are a higher degree of expressability in the code written against the data or objects that are inherently dynamic by their nature, rather than having to express complicated intermediate type declarations and do a lot of o.GetBlahByName("whatever") calls.

The paragraph you quoted from the DLR docs is about language implemantations build on the DLR. Yes of course your apps get the benefits too. The point was more about how, for example, IronPython got way faster not just because of the advent of the DLR but because the CLR itself did work that indirectly improved the IronPython implementation on the DLR.

Don't bother learning the DLR unless you need to add some cached dynamic access to your language or system. Most people do not code at this level of complexity. Most people use languages and frameworks, few people implement them.

F# could use the DLR, but a common misconception is that F# is a dynamic language. It is not. It is strictly statically typed, but it is not explicitly typed in all cases, which is what confuses people. It looks lightweight syntactically due to heavy use of type inferencing and significant whitespace. If F# were one day to decide to add a 'dynamic' type model like C# did, then it would make sense for it to use the DLR for ease of implementation and for interop with C#, dynamic languages on .NET, dynamic libraries and frameworks, etc.

Bill