Usually, I'm not what you would call an early bird. That's why I have read about the new dynamic keyword in C# 4.0 only now. To say it clear: I was horrified. My first intuition was to write an FxCop rule to blame all its usages in the analyzed code. Instead, I wrote this post, which is basically a rant against dynamic - simply because writing a post is much quicker and I felt the urgent need to express my opinion on this, but I'm still thinking about the FxCop thing...
The basic fact is in short, that C# is getting VB-style Variants. This is extremely bad news for someone who once quit his job partly because of a totally rotten VB6 codebase, that was cluttered with Variant-declares. But my concerns are not only personally motivated: The use of Variant all over the place created massive maintenance nightmares, thus occupying most of the companies development resources, and costing tons of money. And the same will happen with C#'s dynamic to the entire IT industry to a certain extent. Its usage might be a time-saver in the short, but it certainly decreases code quality and thus will most likely produce serious maintenance problems in the long run - which is certainly not the right direction to go for an industry that has not quite the best reputation when it comes to things like error-freeness and reliability.
The dynamic keyword opens the door to unsafe typing and gives way to a more careless, lazy kind of coding. Why should I think about what the appropriate variable type may be, when I have the "one-size-fits-it-all" dynamic at hand? In consequence, dynamic makes it way too easy to introduce errors, and it promotes a cultural shift in C# programming style that makes me shudder.
Now I hear the advocates of dynamic say: "When used wisely by well-trained developers, it is a very powerful feature." That's of course true, but it is like saying: "If you always drive your car carefully, you won't ever need a seat belt." Frankly: Would you even consider buying a car that has no seat belts? Certainly not, and you will have a lot of good reasons for it. C# is used for many purposes, in many different contexts, and by many different people with largely varying theoretical backgrounds. Additionally, there sometimes is considerable time-pressure in real life projects. So, if there's the opportunity for abuse, it will inevitably happen!
One of the most cited advantages of the dynamic type is the fact that it greatly eases the interaction with a dynamic language like e.g. Ruby. So code like this...
var runtime = IronRuby.Ruby.CreateRuntime();
ScriptScope scope = runtime.ExecuteFile("SomeRubyClass.rb");
var operations = scope.Engine.CreateOperations();
Object someClass = scope.Engine.Execute("SomeRubyClass.new");
operations.InvokeMember(someClass, "do_something", "someArgument");
...can now be written like so:
var runtime = IronRuby.Ruby.CreateRuntime();
ScriptScope scope = runtime.ExecuteFile("SomeRubyClass.rb");
dynamic someClass = scope.Engine.Execute("SomeRubyClass.new");
someClass.do_something("someArgument");
Now this looks like normal C# code, right? But do we really want potentially unsafe code look like any other code? Shouldn't writing such code be a bit more inconvenient to the programmer by design, reminding him of the fact that such code is inherently dangerous (and there's no way to make it safer with unit tests or some sort of static analysis) ?
Certainly, MS introduced dynamic to satisfy a popular demand that was very frequently uttered. But the collateral damages can be quite serious, by far outweighing the advantages. This well may become another proof of an old proverb: "Beware of what you wish for, you might get it."...