C#4 dynamic keyword - why not?

Question

After reading many of the replies to this thread, I see that many of those who dislike it cite the potential for abuse of the new keyword. My question is, what sort of abuse? How could this be abused so badly as to make people vehemently dislike it? Is it just about purism? Or is there a real pitfall that I'm just not seeing?

Answer 1

I think that a lot of the revulsion that people are expressing to this feature boils down to "this is a bad language feature because it will allow bad developers to write bad code." If you think about it, by that logic all language features are bad.

When I run into a block of VB code that some genius has prefixed with On Error Resume Next, it's not VB that I curse. Maybe I should, I suppose. But in my experience a person who is determined to put a penny in the fuse box will find a way. Even if you empty his pockets, he'll fashion his own pennies.

Me, I'm looking forward to a more useful way of interoperating between C# and Python. I'm writing more and more code that does this. The dynamic keyword can't come soon enough for that particular use case, because the current way of doing it makes me feel like I'm a Soviet academic in the 1950s who's traveling to the West for a conference: there's an immense amount of rules and paperwork before I get to leave, I am pretty sure someone's going to be watching me the whole time I'm there, and most of what I pick up while I'm there will be taken away from me at the border when I return.

Answer 2

Some see it as a tool that will be abused. Like "Option Strict Off" and "On Error Resume Next" in VB which "pure" languages like C# and Java have never had.

Many said the same about the "var" keyword, yet I don't see it being abused, once it became understood that it wasn't the same as VB's "Variant"

It could be abused in places that lazy developers don't want type checking on classes and just try catch dynamic calls instead of writing "if blah is Blah ...".

I personally feel it could be used properly in situations like this recent question that I answered.

I think the ones really understanding it's power are those heavily into the dynamic .NET languages.

Answer 3

dynamic is bad because code like this will pop all over the place:

public dynamic Foo(dynamic other) {
  dynamic clone = other.Clone();
  clone.AssignData(this.Data);
  return clone ;
}

instead of:

public T Foo<T>(T other) where T: ICloneable, IAssignData{
    T clone = (T)other.Clone();
    clone.AssignData(this.Data);
    return clone;
}

The first one, has no static type info, no compile time checking, it's not self documenting, no type inference so people will be forced to use a dynamic reference at the call site to store the result, leading to more type loss, and all this spirals down.

I'm already starting to fear dynamic.

Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused after all, no need to down vote me after 3 years :)