It doesn't infer type information from variable names. (An old version had to do that in one particular case to work around a VBScript ambiguity). It does type inference like Haskell, from the actual types that are assigned to things, so DIM a=9 means a must be an integer.
Again, you're assuming a lot about Fog Creek without a lot of information. The dev team here is extremely happy to be working at Fog Creek. In 8 years only one developer ever left, because he had to move away. Your theory that Fog Creek is "not a very fun environment" seems utterly at odds with what everybody else tells us, which is that they would give their left ear to work here.
By "not a very fun environment" I was referring to the Wasabi programming environment, not the people/social/office environment. Sorry for the ambiguity. I've read most of your essays, and the FogCreek environment seems amazing - you've clearly done a wonderful job with that.
And you're right - I am inferring a lot from not very much information. But, imagine that I'm a hypothetical programmer that was considering working at Fog Creek (I'm probably not up to your standards, but bear with me ;-)). You publicly stated that your compiler infers type information from variable names. That, in conjunction with some other worrisome things I've read about Wasabi, might be enough to push me some other way.
Most of the other places I'd consider working have decent enough benefits (salary, offices, food, etc) that they really aren't a deciding factor. When I look for a job, my primary concern is how interesting/fun the problems/technologies are. As long as all the other stuff is decent, I kind of disregard it.
var in C# is only allowed for local variables, which means you can easily infer the type by analysing the assigment expression, which will always depend on known types. For example method parameters are always explicitly typed.
Haskell style type inference is more tricky, since it also tries to infer the type of function signatures from the different contexts where the function is called. This can lead to circular type dependencies.
"Easily"? I suspect that since C#3 offers lambda expressions that you'd need to use something close to (although probably different from) full H-M inference... in fact, it seems like it may need to be nearly as complicated as Scala's type inference, which is saying something. =)
Again, you're assuming a lot about Fog Creek without a lot of information. The dev team here is extremely happy to be working at Fog Creek. In 8 years only one developer ever left, because he had to move away. Your theory that Fog Creek is "not a very fun environment" seems utterly at odds with what everybody else tells us, which is that they would give their left ear to work here.