I agree. It seems very clear that code readability is reduced by var-like type hiding. When I'm doing code review and I see "var address = contract.getAddress();" what is the type of that variable? I have no idea.
Not sure how this helps. I pretty much knew 'getAddress' would return some sort of Address structure. It's not like knowing the type name tells you what properties are on it. So what's the point?
When did programming suddenly shift away from "the programmer should be aware of what they are doing?"
Hell, I can't count the number of times I've had to troubleshoot bad imports/classpath management brought about by some genius letting his IDE do his thinking for him.
Making it harder to program is not synonymous with making the programmer 'more aware'. I'd argue the opposite. It's much harder to figure out the source of or find all references of something without an IDE. An IDE with intellisense makes the programmer much more aware of what his/her options and navigate large code bases quickly.
String searching text files for definitions or references is just crude.
This, on the other hand, seems perfectly reasonable to me:
var c = new Customer();
Type inference works great imho to avoid specifying the object twice using a normal constructor, not a factory function, and in a codebase where actual classes and not interfaces are specified as method paramethers, though I suspect this is an antipattern ;)
Why would an address be a string? That's poor use of types. I would expect that getAddress() returns an Address. If it did return it as something non-obvious, than I would expect that to be expressed through the interface and thus the call would be getAddressAsString().
Not sure how this helps. I pretty much knew 'getAddress' would return some sort of Address structure. It's not like knowing the type name tells you what properties are on it. So what's the point?