What do you think of the new C# 4.0 'dynamic' keyword?

Question

Hi all,

I've just seen an article detailing the new C#4.0 'dynamic' feature previewed at the PDC 2008 and I wondered what people thought of it ? I'm wondering:

• what are good examples of the benefit of such an addition to the language
• possible disadvantages
• performance implications

I guess people with experience of dynamic languages or else any lucky soul with the 2010 CTPs from PDC may have given it a whirl...

UPDATE: Please do keep posting your thoughts, it's kinda cool to see lists of for / against arguments and, at the very least times that it'll be appropriate and issues to consider.

Benefits:

• dynamic lover with a host of links - Curt Hagenlocher
• New C# 4.0 Features Microsoft reference (docx) - Hugo
• Objective-C comparison - John Rudy
• I think kenny likes the idea
• Visual Studio 2010 and C#4.0 CTPs with language features - Chris Conway
• Interop benefits - ffp
• duck typing - Rob Walker
• ElsticObject using C# 4.0 dynamic features to work with XML

Potential issues:

• Fears of type safety - Steve Morgan
• C# for C# - SoloBold
• On its way to php (and a nice discussion on his blog) - Omer van Kloeten
• fears of abuse - Jonathan Holland
• excusing poor desgin - Robert C. Barth
• C# a Frakenstein child of C - Nelson LaQuet
• Late Binding and co- and contravariance - Thedric Walker
• Wish it was var - Orion Edwards

Answer 1

I see this feature, and the first thing which pops into my mind is the message-oriented architecture of Objective-C. Very cool and powerful, if used appropriately. I haven't had the problem space this addresses yet, but I could definitely see places where it would be useful functionality to have.

The blog post you link to discusses performance somewhat, but bear in mind that CTPs are exactly that: Previews. Until release time, performance measurements don't mean anything.

But wicked cool, nonetheless. The ability to cleanly deal with unknown types rocks verily.

Answer 2

Smells like a duck.

Answer 3

This has been available in boo for a while as duck typing. It also harks back to Visual Basic and COM's IDispatch.

I think it is a worthwhile addition, but am not sure it will prove broadly useful. You need to have a class you know will have a method with a given name at some point in the future but doesn't now.

Reflection obviously lets you specify the method (or property) name at runtime, this doesn't (at least as described in the article).

I'd like to have syntax that lets me write something like:

string method = "Zot";
obj.method();

Where the method name can be supplied at runtime too.

Answer 4

Microsoft has a document describing the reasoning around the new features. It tells you the motivation for them in a prosaic nice way. (Read it!) It talks a lot about using COM and dynamic-language objects from managed code.

Answer 5

FYI... CTP can be downloaded here: http://www.microsoft.com/downloads/details.aspx?familyid=922b4655-93d0-4476-bda4-94cf5f8d4814&displaylang=en&tm

Answer 6

Having recently been buried in IDispatch and .NET, I welcome anything that might make it easier (or even work properly). There are many gotchas in the Interop world and I think that the dynamic keyword as well as the abilities to call-by-name, and provide default values will make this much easier to deal with from within C#.

Answer 7

I dislike it.

Runtime method dispatch is available via reflection, making it easy like this will just make it prone to abuse.

Answer 8

Why not program in a language that isn't built to be C-like? This stuff seems woefully out of place in a strongly-typed language like C#. There's nothing this does that a good application of interfaces and/or inheritance doesn't solve more cleanly in a C-like language. Plus interfaces and inheritance can be checked at compile time.

Someone mentioned objective-C's messaging (well really it was first widely implemented in SmallTalk). This is similar. While I enjoy that feature set in ObjC, what is it doing in C#? Is it adding anything useful? Is it adding anything that a library couldn't add? No. Instead, it needlessly muddies the language and changes its purpose. C# is great partly because it is strongly typed.

There are already good dynamically-typed languages such as Python. They are good if you problem fits their domain and you like using them. Some of us prefer strongly-typed languages and the explicit nature of code written for them. They are both valid paradigms, so don't let someone tell you one makes you more productive (for which types of programs? Under what circumstances?). Writing bank software in Python would be stupid as would writing simple scripts in C#. For everything in between, strongly- and dynamically-typed languages are about even - and that gives developers choice and the ability to code in a style they like.

I'm just saying use the right tools for the job. Don't try to bend a hammer into a screwdriver when you have a screwdriver right next to you.

If you wanted to add something to C# how about more features from the functional programming and/or concurrency world? That could add something and take C# forward; this takes C# in circles.

Answer 9

I'm sincerely disappointed by this new addition.

Compile-time type safety is a massively effective mechanism for eliminating a whole class of bugs.

Bugs that can't be detected until runtime can be very dangerous, particularly if they're associated with edge conditions.

While I acknowledge the need for dynamic typing in certain circumstances, I really think this should be an explicit opt-in design decision, either through the use of a compiler pragma or (preferably, IMO) from a different assembly written in a dynamically-typed language.

Factor in the performance overhead and there's very little positive about it for me.

Answer 10

This really is an explicit opt-in design decision -- you have to explicitly use the dynamic keyword in order to opt-in. :) There are hundreds of ways to write faulty code, and only some of them are caught by static type checks. If you have proper test coverage of your code, then you'll know it's working the way you expect even with dynamic types.

I love dynamic, but then I'm totally biased.

Edit: with regard to performance, the first trip through any dynamic call site is going to be very expensive compared to a normal method call. But subsequent calls should be roughly as expensive as a call through a delegate. That's because information is actually cached at the call site so it's not regenerated on subsequent calls.

Edit 2: I'm a bit curious as to why people think this would be "abused"? Some newbie programmer is going to make his or her code compile correctly by avoiding explicit types where possible and therefore losing out on Intellisense? That hardly seems likely.

Links:

• Anders' talk on "The Future of C#"
• Jim Hugunin's talk on "Dynamic Languages in Microsoft .NET"
• Alex Turner's talk on "Natural Interop with Diverse Object Models"
• Chris Burrows' Blog

Answer 11

It's amazing how instead of going in the right direction (Spec#), the design team is going in the wrong one (DLR).

The dynamic keyword is going be abused so much... C# is on its way to becoming PHP.

Edit: I've written much more thoroughly about this on my blog, with a suggestion on how to improve the feature that you might find interesting.

Answer 12

The pink elephant here is the crappy developers who will make their entire codebase dynamic because it's "easier" or "faster" or whatever silly excuse is usually given for poorly-designed, fragile software, and then you'll get to inherit that mess, and you'll curse the day the word "dynamic" made its way into the C# specification. Because, the simple truth is this: if it's there, people will abuse it. Especially those that don't know any better. And there are a lot of those people in the software engineering field.

Answer 13

The late-binding is not really what I was stoked about. I like the co- and contravariance feature. It means that the CLR is moving closer to Haskell style type class definition which would be cool.

I don't see how the dynamic keyword is a new feature. It seems like plain old reflection to me you just have a keyword for it now. So do you want them to get rid of reflection? Did reflection become a bad thing because it now has a keyword associated to it? I hope not as it is a very handy tool. I agree with Mr Barth. People abuse reflection all the time because the don't know any better. So really, what's changed?

Answer 14

It's awesome. The only thing wrong with it, is that it's not called var

dynamic is too long a word to be used like that. It's similar to if they made you type integer everywhere instead of just int

To clarify: Ideally I would like to be able to use var everywhere, and if the compiler can infer the type, it would, and if not, it would be dynamic. I realise this may not be possible/practical - so for a more realistic solution, I'd like to see the keyword be dyn or dvar or something like that, just to cut down on typing.

Answer 15

dynamic is awesome.

now just give method missing so i don't have to write those classes in ruby.

Answer 16

Dynamic languages are coming to .Net, and C# has to support them. There will be libraries written in the likes of IronRuby and IronPython, and I will want to use them from C# code.

The dynamic type will let me do this easily. Sure, it could be done through reflection, but this way I don't need to clutter my code with noise. As somebody who remembers trying to use OLE controls through an IDispatch interface from C++, I welcome the dynamic keyword.

It will be abused, but that's a fact of life in our business. Show me a language feature that hasn't been bent to the will of a mad programmer on a mission.

Answer 17

Deja vu... ...bringing back what was there in VB 3/4/5/6, "ole automation", com, IDispatch...

I think it will be a useful shortcut to reflection. As many have already pointed out, the potential for misuse is there, but the potential for misuse is always there in so many other language and CLR features.

Bad programmers will write bad code with or without it. Good programmers will write good code with or without it. It will bring a bit more productivity to both groups. (I.e. the bad programmers will write their bad code faster, the good ones will write their good code faster... :) ).

Answer 18

For me the most exciting part is the new dynamic dispatching features in C# 4.0. Dynamic dispatching provides a great way for resolving method calls at runtime. The new dynamic keyword can be used to create dynamic objects, much like

dynamic reader=new DynamicReader();
dynamic data=reader.Read();

Once you've a dynamic object, the compiler is least bothered about any method calls you might make on the dynamic object. The calls will be resolved only at the runtime. In this case, the method Read() is dispatched dynamically during run time.

What is more beautiful is, C# now gives you the flexibility to specify how the dynamic calls should be dispatched. You can implement the IDynamicObject, to write these binders yourself. For example,

public class DynamicReader : IDynamicObject
    {
        public MetaObject GetMetaObject
              (System.Linq.Expressions.Expression parameter)
        {
            return new DynamicReaderDispatch (parameter);
        }
    }

    public class DynamicReaderDispatch : MetaObject
    {
        public DynamicReaderDispatch (Expression parameter) 
                   : base(parameter, Restrictions.Empty){ }

        public override MetaObject Call(CallAction action, MetaObject[] args)
        {
            Console.WriteLine("Logic to dispatch Method '{0}'", action.Name);
            return this;
        }
    }

Answer 19

The dynamic feature will be better understanded. It's just a question of imagination. Finding well designed patters to fit in the dynamic paradigm. I'm sure that a lot of programmers will propose stunning coding solutions that will make our coding more expresive and productive.

Answer 20

Good example for using the C# dynamic keyword is in TDD.

This code doesn't compile because the method "Addition" is not implemented

[TestMethod()]
public void CalculatorThingAdd_2PositiveNumbers_ResultAdded()
{
    CalculatorThing myCalculator = new CalculatorThing();
    int result = 0; 
    int expcected = 3;

    // --> CalculatorThing  does not contain a definition for 'Addition'
    result = myCalculator.Addition(1, 2);

    Assert.AreEqual(result, expcected);
}

With the dynamic keyword the code compiles and the test fails! --> TDD
Because the method "Addition" is not implemented

[TestMethod()]
public void CalculatorThingAdd_2PositiveNumbers_ResultAdded()
{
    dynamic myCalculator = new CalculatorThing();
    int result = 0; 
    int expcected = 3;

    result = myCalculator.Addition(1, 2);

    Assert.AreEqual(result, expcected);

}

More details here

Answer 21

I think a lot of those opposed to the dynamic keyword are assuming that it will get used and abused in pure C# code. The real benefit to dynamic is being able to interface with dynamic or clunky external contexts. For example, being able to reference Javascript objects in a Silverlight application using native language constructs is awesome. Working with Office or COM could also be much cleaner with dynamic.

However, I see little benefit in using it in pure C# applications. Static typing in C#, especially now that we have generics and implied typing, is not burdensome or difficult at all, so you'd might as well benefit from avoiding a large class of bugs.

Answer 22

As most of the developers here are aware, the problems of software development are not caused in any way whatsoever by the structure or capabilities of the tools. They put a man on the moon with sequential programming, and managed to get 3 guys in a metal bin back from the dark side of the moon using a slide rule and trig. You can't tell me that adding dynamic to C# is going to herald the end of the world. The problem is (poor) programmers and that problem, no matter what language gets invented, will never be solved.