VB 6.0 vs. VB.NET

I have an opinion about nearly everything, but I'm on the fence about Visual Basic (VB) 6.0 versus VB.NET. Microsoft and the VB.NET proponents claim that VB.NET is the next evolutionary step for VB—finally bringing to VB some of the advanced features that other languages have enjoyed for years. However, many expert VB developers maintain that VB.NET changes so many established VB features that it isn't even VB anymore. From their perspective, the new product might as well be called FRED.NET.

Related: VB.NET Services and Is VB Dead?

VB.NET injects VB with a wealth of long-awaited new features, including true object-oriented inheritance (even cross-language object inheritance), overloading, free threading, strict type checking, and a new shared development environment. In using betas of VB.NET, I've noticed—and generally appreciated—several changes to established VB coding practices: True should be 1, not ­1, and functions should return values through a Return statement, not through the function name. Changes that are harder to get used to are zero-based arrays, passing parameters by value instead of by reference, and implementing forms as class modules. However, I found that the improved Visual C++ (VC++) compatibility and added capabilities (such as the ability to inherit a form) make these changes worthwhile.

Unfortunately, in a recent announcement, Microsoft said that it's rescinding some of the VB.NET changes, such as the value of True and zero-based arrays, to make VB.NET more compatible with VB 6.0. These minor reversals will do little to help established VB users migrate their code to VB.NET and will hinder the developing VB.NET language's cross-language compatibility—a main goal of the .NET Framework.

However, I agree that VB.NET's features are so significant that they change the nature of VB. The syntax and basic language changes assure that you'll have to rewrite all your existing VB applications to VB.NET. Yes, Microsoft provides a "migration tool," which generates an almost comical to-do list of the code it couldn't migrate—which is almost everything you care about. Rightfully, people who dislike VB.NET maintain that this lack of compatibility with existing VB code guarantees the need to continue to develop and maintain a VB 6.0 code base for the foreseeable future. Furthermore, nearly all the changes in VB.NET make the language more complicated, thereby negating two of VB's strongest points—its ease of use and low initial learning curve.

To provide the advanced language features and Web-development capabilities that experienced developers need, VB needs to change so fundamentally that it becomes incompatible with earlier versions of the language. However, I have so many VB projects in use that I can't foresee giving up VB 6.0 any time soon, and I don't want to use multiple development tools. I'd like to see Visual Studio.NET include support for writing VB 6.0 source code and for compiling projects that use the VB 6.0 runtime. We could then use one development tool and choose whether we wanted to write VB 6.0 or VB.NET applications. This solution would let us have our cake and eat it too.