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…)
VB is VB, which is not supposed to look like C#.
Agreed. Let me add another aspect: software design and construction is an engineering discipline and as such is inherently susceptible to the environment in which it is practiced. This environment (comprised of customers, schedules, feedback, past versions, etc.) imposes costs and unforseen complications that must be addressed. Engineers make decisions using varying metrics, and the further out on the periphery a component or feature lies, the more susceptible it is to the minute day-to-day fluctuations of the environment. Sometimes things "are the way they are" because of randomness introduced by the environment. This isn’t to say that decisions aren’t justifiable, just that no design is perfect.
"Maybe what they should do is just come out say “Hey, we just don’t like them” and then leave it at that"
Because it’s not that at all. It’s a matter of deciding if a language feature is worth it.
Every feature has a cost and in the end you want to get the most bang for your buck out of language. If we could spend 2 days to make a developers life 100 times better, we’d rather do that than spend 100 days to make it only 2 times better.
The purpose of the posts (And subsequent incredibly long conversations) is to come to an understanding of how useful a feature is vs how much trouble we could get into for adding it.
Based on that information it becomes a lot easier to decide what direction to take the language in.
As to your point on Optional parametes. That’s very interesting and I’d never looked at it that way.
However, I’ve also never seen an example of an API I considered well designed that used this feature. 🙂
Cyrus: I don’t think we really disagree on this, my point was just that a lot of the process that you describe is subjective and sometimes you can’t get around that. There’s no objective way to know whether a particular feature is, in aggregate, going to make developers lives 100 times or 2 times better, nor it is possible to know, in aggregate, how useful a feature is. We use our instincts, combined with feedback, to try and approximate this as best we can, but we can never eliminate the human element in all of this…
I believe one of the points Eric mentioned was that the use of static imports, when not obvious, can create a less than intelligable block of code. I would tend to agree. Static imports are not necessarily bad, but their use is contrary to the norm and can, therefore, be confusing.
For example, many build environments utilize NAnt at this point (hurry up MSBuild) and prefer not to use the buggy <solution/> task, but instead use the raw csc tasks. We use a very complex xslt to manage dynamic builds for all projects. When we, the CM group, had our first request for a VB.net project, we were blind sided by the missing Microsoft.VisualBasic import.
Not only that, but it wasn’t even IMPORTED explicitly. It was injected by the IDE. Very bad form IMO.
I personally feel that static imports are an accident waiting to happen, but I could easily submit to an argument supporting them. Trim, Right, etc are staples of the VB language – faking them isn’t going to kill me.
Thank goodness for the WITH statement! I use it in practically every one of my five-to-ten line methods and it make my code *much* clearer and easier to read (it also auto-triggers intellisense just by typing the dot…)
Just another reason I don’t particularly like C#…
I also like with statements, optional parameters and other goodies of VB. I also like the ability to decide how strict you want to be in your code. I generally like the idea that VB gives the developer an option to select what is best for him in the current situation.