Dynamic Programming with C# 4.0

Yesterday Joe Mayo talked to the South Colorado .NET User Group about the new features of C# 4.0.  The most interesting change is the addition of the “dynamic” datatype.  This datatype allows developers to declare a variable that is not actually typed until runtime.  This is different than the “var” keyword which actually types the variable using the return value from the right side of the equals sign.  Let’s take a look at a quick example:

   1: private void Main()
   2:         {
   3:             Dog thisDog = new Dog();
   4:             AnimalSpeak(thisDog);
   6:             Cat thisCat = new Cat();
   7:             AnimalSpeak(thisCat);
   9:             Frog thisFrog = new Frog();
  10:             AnimalSpeak(thisFrog);
  12:             Bird thisBird = new Bird();
  13:             AnimalSpeak(thisBird);
  14:         }
  16:         private void AnimalSpeak(dynamic Animal)
  17:         {
  18:             Animal.Speak();
  19:         }
Notice on line 16 the parameter uses the dynamic datatype.  This allows us pass in any object and try to call the Speak method.  Also take notice we are not using an interface to ensure there is a Speak method on the object.  So, we lose the benefits of strong typing and if the object passed in does not contain a Speak method we get a run time error. 

The dynamic datatype is very powerful, especially when it comes to dealing with COM interop.  It also will aid test driven development (TDD) by allowing developers to write unit tests without worrying about the actual implementation of the objects they are testing until after the tests are written.  Again very powerful.

However, with great power comes great responsibility.

I feel that there are a couple issues with dynamic programming.  It seams we have come full circle with .NET.  I remember when .NET first came out and everyone was promoting type safety as a huge benefit.  Now with dynamic programming we can bypass type safety and just wing it. One problem I have with this is that the errors are runtime errors.  So, for example lets say we are accessing a COM object dynamically.  In our dev environment we have a the new version of the COM object that supports some new functionality we are using.  If we move the application to test or prod and forget to upgrade the COM object, the application may start and run without a problem but will bomb at runtime whenever a user tries to access that one section of our app that is using the new functionality.  To me this puts too much emphasis on QA testing when the application still compiles but may bomb at runtime.

Another disadvantage of dynamic programming is the lack of intellisense.  If you declare the variable as dynamic then intellisense will not work.  Again, this opens up the issue of misspelling some of the properties or methods that will not get caught until runtime.  I really like intellisense so I will not use dynamic unless it is the last option.

My fear is that many developers will get lazy with dynamic programming and use it in the wrong situations.  Using it as a replacement for using interfaces or good old fashion reflection may cause more runtime issues that slip past testing and hit production users.  Some developers may see that as job security.  I see it as a sure fire way to lose customers.

Posted in Labels: , , , |


  1. Anonymous Says:

    What you seem to be worried about is bad programmers. If they are bad then they shouldn't be programming.

    Dynamic variables has their place like anything else. If sloppy programmers use them in the wrong way then that's for their bosses to worry about.

    If you give a programmer a hammer and he hits his thumb, doesn't mean hammers are not useful.