Guest Opinion

Don't Include VB6 With VS.NET

The recent petition from a group of Microsoft MVPs notwithstanding, it would be a mistake to incorporate a version of Classic VB in a future version of Visual Studio.

A group of Microsoft MVPs has recently surfaced a petition to merge the VB6 IDE into Visual Studio 2007 (or whatever comes after 2005).

I, too, am a Visual Basic MVP, but I do not favor the idea of merging the VB6 IDE into Visual Studio. I just don't see this as a practical idea, for many of the reasons Paul Vick lists in a recent blog. The fact of the matter is, the only real factor in how long VB6 continues to be used will be how long businesses continue to find VB6 financially viable.

The issue itself appears to be spinning out of control, not least because various media outlets are jumping in. The blogsphere and numerous trade publications have gone berserk over the subject, writing both pros and cons. (Editor's note: VSM itself ran an editorial by Karl E. Peterson wherein he explained why he sponsored/supported the petition "Support Classic VB," [May 2005]).

I've been in this industry for nearly 20 years. My first job was porting code from PDP-11 to VAX. But there were still companies running that PDP-11 software 10 years after the hardware was no longer manufactured.

The lesson? Companies run old, dead technology.

They do so because it works. Companies are nothing if not pragmatic, and that's OK. But none of those companies expected DEC to support the long-dead PDP. They built their own support network through user groups and a sub-industry of recyclers who sold refurbished parts for many years after nothing new was made.

VB6 is the PDP-11 of today. Support is ending, though technically Microsoft has support options through 2008.

And you know what? Companies will continue to run VB6.

Again, because it works. Microsoft would prefer that you upgrade, but you don't have to. And that's OK. However, like the people running the PDP-11s, you can't expect Microsoft to support a dead tool. This is especially true because Microsoft has provided a far superior alternative to the discontinued tool in the form of VB 2005.

It's cool with me if you want to keep using VB6. More power to you, even. That said, you do need to accept the costs of handling your own support if you choose to do so—as does anyone who chooses to continue using dead technology.

I'd be willing to bet a decent sum of money that none of those old companies I mentioned previously continue to run PDP-11 today. The reason: The cost of using a dead technology eventually outweighs the cost of moving forward. Businesses that depend on such technologies eventually must face the fact that there comes a time when it is more expensive to continue relying on a dead technology rather than adopt a newer, more productive, technology.

This analysis will eventually hold for VB6, as well. It is simply a cost/benefit decision at a business level, nothing more. For some time to come, it will be cost-effective to maintain VB6 code, even though the technology is dead. Eventually—whether it is five, 10, or 20 years down the road—the cost differential will make it far more effective to move to a more modern and supported technology.

I doubt that many developers would choose to continue to use VB6, apart from a few odd ducks. Certainly, few developers would choose to continue using VB6 after using the more recent versions of VB.NET or VB 2005 for a few days. I've seen countless people make the migration, and none of them are pining for the "good ol' days of VB6" after using VB.NET. Mostly, this is because VB.NET is just so damn much fun!

Press the VB6-focused MVPs, and you'll find that they stay with VB6 for business reasons, not technical ones. Their customer bases are pragmatic, conservative, and remain at the point where the cost of running a dead technology is less than switching to a more modern technology. And that's OK. That's business.

What irritates me is when people let emotion into the discussion. This shouldn't be a dogmatic discussion.

It is business, pure and simple.

The opinions expressed in this editorial are those of the author and not necessarily the opinions of VSM. This editorial was adapted from a blog posting by Rockford Lhotka at www.lhotka.net/weblog.

About the Author

Rockford Lhotka is the author of several books, including the Expert VB and C# 2005 Business Objects books and related CSLA .NET framework. He is a Microsoft Regional Director, MVP and INETA speaker. Rockford is the Principal Technology Evangelist for Magenic, a Microsoft Gold Certified Partner.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube