Losing your (type) religion
As I stated in my last post, the var keyword is an acknowledgement that I do not care what the type of the variable is - I only care what it can do.
Into the IUknown
Most developer start on the path to this revelation when they discover interface-based programming.
Consider: we need to write a method that returns a collection of strings. Callers of the method will only need to loop over the items and perform some action. The number of elements to return is not known at compile time, so we'll declare a generic List<string>, populate it within a loop, and then return it to the caller.
The junior developer will declare the return type of the method as List<string>:
List<string> GetNames(){}
Acknowledging that callers should not be bothered with having to know an implementation detail (the fact that a List was used instead of a fixed-sized array), and knowing that they only need to loop over the returned items, a more experienced developer might declare the method:
IEnumerable<string> GetNames() {}
Which means any variable the receives the return value will also be typed as IEnumerable<string>:
IEnumerable<string> names = GetNames();
Here's the kicker - in both scenarios, the GetNames method is really returning an object of type List<string>! When the supposedly more experienced developer chooses to return a more abstract type like IEnumerable<string>, type information is lost. Yikes! The names local variable above holds a List<string> instance, but you (the client developer) don't know it. As scary as that might sound, you probably realize that you don't care. As long as you can do the things you need to do with names (loop over it), you are happy.
Walking like a duck
Now let's take that train of thought and consider duck typing in a dynamic language like Python. I can declare the following method:
def Recycle(service):
service.Stop()
service.Start()
It takes a single parameter named service. What is the type of the parameter that is expected? I don't know. And after the initial anxiety settles, there is the liberating realization that I don't have to care! All I know, or care, is that any object instance that is passed to this method must implement a Start() and a Stop() method. The same method can be used with instances of a Lawnmower, AuditLogger, or SongPlayer class (assuming they all have Start and Stop methods).
Getting closer to the goal
Let me be clear - I am not suggesting that implicit typing in C# 3.0 is the same as duck typing. What I am suggesting is that the 2 examples above are points along the "progression of understanding" of the same concept: it is the behavior of an object that really matters, as opposed to the type name that is attached to it. Interface-based programming is near the start. Implicit typing is further along the progression. Duck typing is closer to the end.
I think we will find that programmers who have been exposed to and understand languages which support duck typing will be more likely to be comfortable with and embrace the var keyword. They have already made the mental leap that type information serves the computer more than it serves the human. If you haven't yet, do yourself a favor and learn a dynamic programming language, even if you know you will continue to spend your days with static typing.