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

  • Creating Reactive Applications in .NET

    In modern applications, data is being retrieved in asynchronous, real-time streams, as traditional pull requests where the clients asks for data from the server are becoming a thing of the past.

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

  • .NET 9 Preview 3: 'I've Been Waiting 9 Years for This API!'

    Microsoft's third preview of .NET 9 sees a lot of minor tweaks and fixes with no earth-shaking new functionality, but little things can be important to individual developers.

  • Data Anomaly Detection Using a Neural Autoencoder with C#

    Dr. James McCaffrey of Microsoft Research tackles the process of examining a set of source data to find data items that are different in some way from the majority of the source items.

Subscribe on YouTube