Eric and Cyrus have been expending a non-zero amount of energy trying to rationalize why they think static imports are bad. Maybe what they should do is just come out say “Hey, we just don’t like them” and then leave it at that. It seems like that would save everyone else a lot of energy arguing about what, in essence, comes down to a matter of taste.

VB has had static imports since VB 2002 and the world seems to still be turning happily on it’s axis. (Actually, in addition to static imports we have standard modules, which are even worse.) We haven’t been getting lots of complaints about unintelligible code being written because of it. We haven’t seen lots of horribly designed APIs being produced. Which isn’t to say that I don’t believe that there aren’t people out there abusing the feature (and shame on them!), just that by and large people seem to have taken the feature in stride and used it where appropriate. And I’m pretty confident that Java is going to see pretty much the same thing.

But, really, I don’t think it’s a horrible thing that C# doesn’t want this feature. As much as we like to dress up language design in processes and official sounding specifications, so much of what passes for language design comes down to the particular views of the particular people designing the language on some particular day. Language is almost infinitely malleable and often times the “best” way of doing something is not particularly clear – if you ask 10 different people about some particular design point, you’re likely to get somewhere between 8 – 10 different answers. Hell, if you ask the same person about some particular design point on two different days, it’s possible you’ll get two different answers. (It’s not like every single language team at Microsoft hasn’t backtracked on something at some point…) So even though rigorous intellectual analysis forms the foundation of language design, gut instinct (based on past experience, usually) can often be the decisive factor. And there might just not be any neat, logical, defensible reason why we choose to do this and not that, or implement something this way and not that way.

I think the same goes for stuff like the With statement, too. Although not everyone on the C# team might hold the same opinion on features like these, on the whole they’ve come to the conclusion that they don’t like the features, and I think that’s fair enough – they get paid to make those kinds of decisions, after all. It’s not like they haven’t bent over backwards to listen to community feedback and gone to great lengths to consider that feedback. It seems like in those cases a “Yup, we considered it, thought about it for a long while and ultimately decided it didn’t seem like a good idea. However, we’re always open to reconsidering the decision if things change.” would be sufficient….

(I will quibble with one of Cyrus’s points, though: I don’t believe that the Office API is the way it is because it was mangled to cater to the features of, oh, let’s be honest, VB. The Office API is in many cases the way it is because it had to be designed/mangled around the past limitations of the VB language. The Excel object model is so untyped in places because it was written before OLE Automation had type libraries and could express types other than VARIANT. All the Office applications abuse optional parameters to death because VB didn’t support overloading before VB 2002. And so on, and so on. The abuse of optional parameters is a particular shame because I think (and this is just personal speculation) that that is one of the reasons C# doesn’t support them. I can always hope they’ll see the light though…)

Bill whinges a bit about the fact that date literals in VB are expressed using the U.S. date format, which is (of course) different that what most of the world uses. It’s a legitimate gripe, but there’s not much to be done about it. The cardinal rule that we follow with the language is that the current locale settings of a machine should never affect the compiler’s output. Thus, everything expressed in the language that’s processed at compile-time has to be in one canonical format and cannot be locale-dependent. And, of course, somewhere back in the mists of time when the canonical format was chosen, it just happened to be the format of the home country of the software… (This is also why you can’t do string conversions in constant expressions – string conversions are locale sensitive.)

It’s true, though, that the IDE used to be much more permissive about what it accepted as a date literal that you typed in (and which it would then convert to U.S. format). When we moved to .NET, we stopped using VarBstrToDate to convert strings that were input from the IDE and instead started accepting only legal canonical date strings. I don’t exactly remember why it was we did that, though…

I will add that VarBstrToDate is a very, very, very scary piece of code. As Greg Low notes in the comments on Bill’s entry, the old COM date conversions routines (on which IsDate is based) will do some truly wacky things. During the year and a half that I owned OLE Automation, I had to spend a good bit of time in the code for that routine and the finite state machine that it uses to try and recognize dates. Rather than just accepting the current locale, it has all kinds of weird logic to try and guess what you meant based on what’s possible. So if you call the routine on “24/1/04” using the U.S. locale, it’ll still parse it as January 24th, 2004 because it figured that the “24” is most likely a day value and that you were entering it in dd/mm/yy format. On the other hand, if you call the routine on “1/3/04” using the U.S. locale, you’ll always get January 3rd, 2004. Scary stuff.

(I also heard tell that at one point back in the mists of Excel 5 days, the VB team experimented with allowing the language syntax to be localizable. So you could say, I don’t know, “Por x = 1 a 5 : Escribe x : Siguiente x”, if you pardon my horrible Spanish. This turned out to be such a horrible idea that they quickly dropped it and never looked back. But supposedly the legacy lives on in OLE Automation and the fact that IDispatch takes a locale ID when converting names to DispIDs (i.e. so that you could have different method names for different languages). I can’t vouch for the absolute truthfulness of this story, but it’s one of those stories that’s “too good to check.”)