A few days ago Scoble emailed me with the heads up on his post talking about the MVP revolt spurred on, in part, by the fact that VB 6.0 mainstream support is ending this month. Then life intervened and I’m just now getting some time to get back to the whole brouhaha. In the meantime, this has roiled through at least a few corners of the blogsphere. I’d throw in a couple of gratuituous links, but if you read any number of .NET or VB blogs, you’re going to have seen them. Well, OK, two entries that stand out in my mind were those of Dan Appleman and Scott Swigart. There were plenty others that I although thought were good, but one man can only link so much. The petition itself can be found here.
I should start off with the statement that I have a great amount of sympathy for people who have not yet made the move off of VB6 and who would very much like to see support extended even further than it already has. I know that support can be a real issue and is something that people worry about. Beyond that, though, I can’t really say anything because I’m not even remotely involved or included in decisions about things like product support. I, along with the rest of you, will be interested to see what kind of response the outcry elicits.
As for the petition itself, it asks for two main things: 1. That we develop new versions of “unmanaged VB”, and 2. That we integrate those new versions of “unmanaged VB” into the Visual Studio shell.
To start with the second point first, to those who think we should integrate VB6 into the current Visual Studio shell, I can only offer the perspective of a developer who’s worked in both codebases: best of luck. In VB6, all of the pieces of the puzzle (compiler, debugger, forms package, runtime, etc.) were designed to work solely with each other and were tightly bound together. In Visual Studio, all of the pieces of the puzzle were designed to work with mutiple clients and were loosely bound together. Thus, the architectures are totally different and, in many ways, incompatible. Heck, we spent four years getting VB .NET integrated into the Visual Studio shell and we were writing it from scratch (and therefore could design a compatible architecture)! Trying to extract some of the pieces of VB6 and fit them into an architecture that was not designed to couple with them as tightly as their previous home would be a huge undertaking.
And when I talk about a “huge undertaking,” I’m not talking huge in terms of fungible stuff like money or people. I’m talking huge in terms of non-fungible stuff like time. No matter how much money or how many people we threw at the problem, it would still be a significant amount of time before anything could be produced. I’m talking, like, years. So, now we’re talking about having something in, what, 2007? 2008? At best? Ten years after the previous version of “unmanaged VB” shipped? I’m not really sure how that’s going to make much of a difference to the issues that people are confronting today.
Now, obviously, we could still satisfy the first request by shipping a new version of VB6 that wasn’t integrated into the Visual Studio shell, and that would take a lot less time. At this point, though, I don’t believe that even that would really buy people that much. Leaving aside the question of the desirability of a separate-but-sort-of-equal development envrionment, Microsoft has stated very clearly (pace Richard) that managed code is the direction that our company’s components and APIs are headed. As such, fostering new development (as opposed to extending support for existing development) in “unmanaged VB” doesn’t just postpone the inevitable, it makes it worse. It encourages people to keep writing a lot more code that, somewhere down the road, they’re going to have to port to .NET. It’s alleviating pain in the short term only to cause greater pain the long term, something that I don’t think it would be responsible for us to do. (One part of the petition that did mystify me a bit was the request to “Ease […] migration of unmanaged VB/VBA code to VB.NET.” Does anyone think that we haven’t been working on that?)
So, while I can be sympathetic to where the petitioners are coming from, I can’t ultimately support their stated goals. Obviously, we continue to have work around helping people make the transition from COM to .NET at their own pace and helping them be clear on the advantages of doing so. VB 2005 is going to help a lot here, I think, and we continue to work on even more things for the road beyond. In the end, I think that’s the best thing we can do.