Here's a surprise: Many Microsoft Visual Basic MVPs are upset about the lack of further development of VB6 (ie, not VB.NET). In fact, many have signed a petition (here).

I don't mean this disrespectfully, but: let it die. I don't say this is a smug anti-VB person -- I love VB6, and have used it extensively. However, I just don't see why Microsoft should regress and support VB as the petition recommends. Let me explain by addressing the points in the petition:

1. Preservation of assets

This is main reason for the petition: it breaks down to the fact that VB.NET is not backwards compatible with VB6. With new versions, according to the petition, we should be able to "compile existing projects and produce identical results."

Um, no. Backwards compatibility should be a priority whenever possible. Eventually, there will come a time when things need to break for the sake of future development, for evolution. Love or hate .NET, VB6 simply won't work with the .NET architecture.

If you need to compile a project and produce identical results, then use the same compiler. If you want to slowly migrate a complex application to .NET, begin with some assemblies, one at a time.

Support the core VB6/VBA Visual Basic language and syntax;

Again: no. VB.NET, for the first time, is fully object oriented. Supporting the "core VB6" language and syntax is a huge step back. If this is required, again, just stick with VB6 -- there's nothing wrong with that!

2. Continued support for the Visual Basic language
Microsoft should demonstrate a commitment to the core Visual Basic language.

I view VB.NET as commitment to VB as language. It's just not the way these people want it.

3. Ease of migration of unmanaged VB/VBA code to VB.NET

The decisions of if, how, and when to migrate code to .NET should lie with the customer. Some may choose to remain with unmanaged VB, especially for legacy code bases. Some will use only VB.NET, others a mix. A future version of VB6/VBA should treat all these options as valid, while making it easy to move among them.

How can you not do this? I do understand what they mean: they want it under a single IDE, so you can manage your projects in whatever version concurrently. This would be cool, but I personally don't see it as a big deal. In fact, if anything it could be just confusing.

I just don't see how the option of how to migrate to .NET isn't in the hands of the customer. I stumbled on the petition by reading the Blah-Blah blog (here).
There's some points here that I just don't agree with:

"...the .NET version of Visual Basic is Visual Basic in name only."

No it's not; it's true that a VB6 project of any reasonable complexity will not compile in VB.NET ... but a language is typically defined by its syntax (of course there are more subtleties to it); the "look and feel" of VB.NET is very familiar to VB developers. I know because I transitioned.

Like many other developers, I don't have the time, energy, or desire to un-learn the substantial skills I've acquired in over 20 years of coding with Microsoft Basic

This statement says a lot, and I hate to be critical but there is no "un-learning" that needs to be done. This statement, to me, says, "Yeah, I just don't want to learn something new." Computers and programming is still a young industry and requires adaptability. I'd hate to think that someone could be so rigid in their skill set. (I'm having flashbacks of mainframe programmers loathing XML for similar reasons.) I'd hire someone with a minimal skill set but burning desire to learn and grow over someone stuck "in the box."

Anyway, this is just my take on the subject. Further splintering of VB would be a mistake, in my opinion. I realize more has been done for C++ than has been for VB in Visual Studio .NET, and I'd wager to say that is a sore spot among VB developers. Still, I don't disagree with the direction Microsoft has taken; if there were a petition to protest the petition, I'd sign it. :)

Related posts

VSTS BriefingsJust saw the following events coming soon to Raleigh and Charlotte (as well as couple of other locat...MSDN Roadshow -- coming soon!We're back!In a few weeks, we'll be bringing the MSDN Southern Fried Roadshow to NC and SC! No...Flash -- no x64?I can't believe I haven't noticed this sooner, but Flash doesn't support 64-bit?!http://kb.adobe.com...

Visual Basic, like any programming language, is just a tool. Developers who are unwilling to move to a new environment and a new language are just lining up for a pink slip.

I've coded Visual Basic since about 1994, and I still maintain apps written in it. I've transitioned to C# for new projects, and while I must admit that I'm still more productive in VB at this point, I have a lot more fun coding .NET.

As usual, the real losers in the technology march are the customers, particularly those who use custom-developed software. Eventually, you have trouble finding developers who can support your code, or changes to the operating system make it stop running, or some other form of techrosion forces you to replace it. Then you have to pay to have your software rewritten, with a fresh round of debugging, by developers who are learning on your dime. This is frustrating to users who don't need new functionality and don't care much about technology in the first place. I can certainly attest that, while I get excited about what I can do with .NET, my customers don't care and don't want to know (.WHAT?).

I can relate to their plight. I would be happy using the same version of QuickBooks I used 8 years ago, but operating system upgrades and the need to get payroll table updates forces me to upgrade every other year at least. From my perspective, Intuit has added almost nothing useful to me in the more recent versions of their product. But they keep holding out their hand and I keep putting money into it.

What I'm getting at here is I agree with Mr. Hitney: Stop living in the past. The only concession I see MS making to die-hard VB programmers is continued support for the language (e.g. service packs) and COM in future releases of the operating system. Trying to wedge VB6 syntax and its extensions into .NET is just a bad idea. In fact, I believe that anyone who uses a code converter to move their VB6 projects to .NET is making a huge mistake. You just end up with bad .NET code.

On the other hand, there are obviously a whole lot of VB6 programmers out there who are perfectly happy right where they are. MS created this market, and it only makes business sense for them to support it. If not, then MS should license the language to someone like Borland who could milk the remaining market for the rest of its natural life. If MS is afraid of how well .NET could compete with a continuing VB6 market, then perhaps they need to rethink their strategy.