Monthly Archives: July 2004

Time ever marches on…

Now that VB 2005 Beta 1 has shipped, the time has come to start doing some “long lead” work on versions beyond the 2005 release. What this means is that while 98% of the team remains focused full-time on finishing the current product, a few people get to start spending some of (though hardly all of) their time thinking about the kinds of big issues that we might want to solve in the next version(s). A good way of thinking about it is that before a version ships we try to lay some of the groundwork for the next release so that when the rest of the team is ready to engage on the next version down the road, we can hit the ground running. (Other teams are also starting to do some of this work, too.)

At the moment, I’m spending my long lead time thinking about two major things. One is: what can we learn from scripting languages? We sort of discussed this back in March, and now I’m returning to the question, both in terms of the question of development environment and in terms of the question of dynamism. (Which is also interesting given that the CLR hired a scripting language implementer specificially to work on making the CLR better for dynamic languages.) The other is: what can we do to improve data access? This is something that other languages are thinking about as well. My interest stems not just from the fact that people find it difficult at times, but from the fact that my first job at Microsoft involved working a lot with SQL and data access (I worked on the query designer in Access) and I’d like to see us improve in that area.

Those are just the two things that I’ve started with, but there’s certainly room for other things as well. What other things would you like to see? I’m not talking about features (you can go submit those requests here and the product teams will see them), I’m talking about big picture areas like the ones I mentioned above. What areas do you think we could do better in? What areas do you think there is untapped potential? Can’t promise I’ll look at everything, but I’m curious to see what people might be thinking.

(Since we MSFT bloggers often get dinged for talking only about the future and never about the present, I should add the disclaimer that I don’t plan on talking too much about this long lead work for the forseeable future. This blog is still going to properly remain focused on VB 2003 and VB 2005, not on random ideas about the future that may or may not ever come to fruition. There’s been way too much of that at Microsoft in the past.)

We are experiencing technical difficulties, please stand by…

As I’ve said before, I host my own website which means that I’m responsible for my own DNS resolution. For a long time, I used the free service provided by Granite Canyon as a secondary DNS server, however that service started becoming more and more unreliable this year and appears to be largely dead. Searching for another source of secondary DNS hosting, I hit upon secondary.org, which seemed like a good place to get some free backup DNS hosting. Big mistake.

Sometime over the weekend, it appears that secondary.org has been taken over by someone who’s started redirecting all DNS requests to some random website. Depending on which DNS server your machine chooses when resolving panopticoncentral.net, you’ll either get my website or not. Last night I moved all my DNS hosting over to Network Solutions which at some point started offering free DNS hosting to people who register with them (all the better to sell their web and mail hosting). As that change propagates itself throughout the DNS system of the Internet, the connection to this server should become reliable again. I apologize to everyone who’s been redirected against their will…

Why no ++ and –, redux

Since we’re on the subject of language differences today, it’s worth noting that Eric Lippert wrote his own entry on why he thinks VB shouldn’t have ++ and —. I’m not sure if he saw my original thoughts on the subject, but it’s interesting to see the similiarities and differences in reasoning. Eric also privately asked me about a different reason for not requiring Partial on partial types, but I’m going to cover that later this week – I’ve blogged enough for today.

Language harmony

In the comments to my previous entry on partial types, mustTryHarder comments:

If C# always uses the partial keyword (and presumably went through the same level of debate) then why did the VB team approach it differently? I assume you guys talk to each other. I can’t see how Microsoft can justify a difference. While virtually everyone agrees that separation of designer code is desirable, it would appear that only the VB team feel the Partial keyword is optional. IMHO the VB team would do well to listen to feedback on syntax in order to avoid the same back-tracking in future that happened with areas such as properties which are now once again able to specify different accessibility levels for Get/Set. So far your private debates have got it wrong!

mustTryHarder’s comments are contradictory, although there was no way for him to know that ahead of time. You see, the reason why VB didn’t support properties with different levels of accessibility in VB 2002 and VB 2003 is because the C# team didn’t want to support them. Our original plan was to include them just the way they were in VB6 but the C# design team was very definite that they thought they were a bad idea and that they weren’t going to include them in their language. As a result, when the C# compiler came across a property with different levels of accessibility, they would consider the property’s accessibility to be the more restrictive of the two. So if we’d gone ahead and implemented the feature anyway, a property with a Public Get and a Private Set would have been considered Private by C#, which would have looked a lot like a bug to most people. So we made the decision to not implement the feature in the interest of playing well on the .NET platform. Fortunately, everyone’s come around in VS 2005, so the feature is going to appear in both languages and there aren’t going to be any difficulties.

So, ironically, in this case we’re getting simulateously criticized for not doing the same thing as C# is doing and for doing the same thing as C# did. Welcome to the world of multi-language programming on the .NET platform, folks. We’re not in Kansas anymore.

The truth is, we have a lot of regular contact with the C# team about design decisions and feature choices and, where it makes sense, we try and be harmonious. However, each language’s design team has distinct visions for their language and that is inevitably going to cause divergence. For example, I know that more than a few people on the C# team (and more than a few C# users) think that our generics syntax is stupid. I can see where they might be coming from in having that opinion, but I disagree with it… and that’s the way it goes. Should VB users not get Edit and Continue because the C# team doesn’t think that it’s important enough to ship in VS 2005? Should C# users not get iterators because VB doesn’t think that it’s important enough to ship in VS 2005? Who gets to decide which vision is the “right“ one? Who’s even to say that there is a single “right“ vision for the millions and millions of developers out there in the world?

I should be clear that what I’m not saying is that people shouldn’t feel free to complain loudly about things that they don’t like about VB. That feedback is invaluable and helps guide the future direction of the language. What I am saying, though, is that one argument that is never going to work with us is “But C# does it differently and you both should do everything the same way!” If there are concrete reasons why you think the C# design is better, then let’s hear them and we can have a good discussion about the merits and demerits of the VB approach. Otherwise…

Language wars and Kilkenny cats

I try to stay out of the language wars as much as possible, and I’ve particularly sat this round out because it was started by a company who’s trying to sell something. However, the word that A Word A Day sent out today seemed strangely appropriate. The word was “Kilkenny cats” and you can read more about them here. I particularly liked the limerick:

There wanst was two cats of Kilkenny
Each thought there was one cat too many
So they fought and they fit
And they scratched and they bit
‘Til instead of two cats there weren’t any.

Appropriate…

Why don’t partial types require partial on all declarations?

Andy Maggs asks:

Who thought it was cool to be able to create partial classes without indicating on the ‘primary’ class that it has other parts somewhere else. In C# you must use the partial keyword on all parts, so why not VB?

Since partial type cannot span projects (i.e. a type must be fully described inside of a project), we felt it was sufficient to only have to have at least one of the declarations “opt in” to partialness. Requiring every partial declaration to have to specify that it was partial seemed to be unnecessarily strict. For example, in the designer case such as a WinForm, it is really necessary to put “Partial” on the class declaration when the partial type that the designer spits isn’t even shown by default?

And, of course, there’s no reason that a developer can’t specify “Partial“ on all partial declarations if they so choose. You can even modify, say, the WinForms template to add it if you want.

In the end, this is one of those things I was talking about just last week, a real judgement call. There are more than a few people who have taken issue with this particular decision, feeling that the more explicit the better. (There have been even suggestions made to us that partial types should have to explicitly state which source file the other partial types reside.) I can see their point and don’t think their arguments are bad, we just don’t happen to agree on this…

Boo to you, too!

Don pointed to the release of a new .NET programming language called boo. I downloaded the boo manifesto and took a look and it seems very interesting (and it’s nice to see some language experimentation going on on the CLR!). Some of the ideas aren’t unfamiliar – C# already has iterators and we’ve kicked around the idea of being able to enable late binding on a per-variable basis (called “duck typing” in the manifesto) – but others are less familiar. One idea I’m curious about seeing how it plays out is extensibility in the language. In the manifesto Rodrigo says:

I wanted a language I could extend with my own constructs.

This is one of those ideas that’s always seemed to me to be great on the face of it but questionable because of the law of unintended consequences. On the one hand, how can you argue with giving people the ability to extend the language as they see fit, especially given the fact that compiler releases can be a year or more? On the other hand, it’s so easy to screw up language design even when you’ve been doing it a long time that I wonder if you won’t quickly have a language that’s no longer comprehensible by man or machine.

One thing that Rodrigo loves about .NET is the nice way that the entire set of class libraries are architected together in a pretty clean and consistent manner. This is a great advance over the hodgepodge approaches of the past where fundamental libraries were incompatible or worked in entirely different ways. I wonder, though, if allowing extensible languages isn’t taking a step backwards into that world. Central control of a language ensures some reasonable amount of consistency in thought and design – if anyone is allowed to add extensions, will the language gradually devolve into the language of Babel? Or will only extensions that preserve the core style survive while the others die off? I guess we’ll just have to see.

I will add that one major problem with our compilers today is that entirely too much information is locked up in them. We’ve started exposing compilation information through mechanisms such as the Visual Studio code model, but we need to go a lot further to enable more advanced and extensible tools. It’s certainly possible to expose a lot more information about what exists in the code that’s being compiled without having to make that information modifiable outside of the compiler, and I think that’s something that’s unquestionably worth pursuing in the long run.

Zero-impact projects rock!

OK, I’ll admit it – there are actually times when I think features that we’re introducing are stupid. (Of course, they’re always someone else’s features, never my own…) One such example was the reappearance of something we call “zero-impact projects.” A zero-impact project is a project that is created on-the-fly in a temporary directory rather than being saved somewhere permanent like your Projects directory. You don’t have to create something permanent until you do something like shut down the IDE or close the project. VB6 did this, but VB7 didn’t, and I personally never thought much about it. When I found out we were doing the work to restore it, I though, “Ah, that’s dumb. Who really cares about this? All it does is save you having to pick a place for your project… Grumble, grumble.”

Well, let me publicly eat my words: munch, munch, munch. I’ve switched to VB 2005 Beta 1 full time for the stuff that I’m working on and zero-impact projects absolutely rock! One of the things I’m doing right now is updating the language specification for VB 2005 and it’s just great to be able to bring up VS, create a VB project, play around for a little while and then close down VS without having anything left behind on my computer. No more “ConsoleApplication491349” projects! I mean, I was right in one way – it’s a little thing, but, boy, it does make a difference. (The faster startup time of the IDE also helps immensely.)

If you aren’t using the VB profile, you can enable zero-impact install by clicking on the “Projects and Solutions” entry in the Tools | Options dialog and unchecking “Save new projects when created.” It’ll even work for C# projects! (Although this feature might be a little too “edit and continue”y for those C# folks… <g>)