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

  • VS Code v1.99 Is All About Copilot Chat AI, Including Agent Mode

    Agent Mode provides an autonomous editing experience where Copilot plans and executes tasks to fulfill requests. It determines relevant files, applies code changes, suggests terminal commands, and iterates to resolve issues, all while keeping users in control to review and confirm actions.

  • Windows Community Toolkit v8.2 Adds Native AOT Support

    Microsoft shipped Windows Community Toolkit v8.2, an incremental update to the open-source collection of helper functions and other resources designed to simplify the development of Windows applications. The main new feature is support for native ahead-of-time (AOT) compilation.

  • New 'Visual Studio Hub' 1-Stop-Shop for GitHub Copilot Resources, More

    Unsurprisingly, GitHub Copilot resources are front-and-center in Microsoft's new Visual Studio Hub, a one-stop-shop for all things concerning your favorite IDE.

  • Mastering Blazor Authentication and Authorization

    At the Visual Studio Live! @ Microsoft HQ developer conference set for August, Rockford Lhotka will explain the ins and outs of authentication across Blazor Server, WebAssembly, and .NET MAUI Hybrid apps, and show how to use identity and claims to customize application behavior through fine-grained authorization.

  • Linear Support Vector Regression from Scratch Using C# with Evolutionary Training

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the linear support vector regression (linear SVR) technique, where the goal is to predict a single numeric value. A linear SVR model uses an unusual error/loss function and cannot be trained using standard simple techniques, and so evolutionary optimization training is used.

Subscribe on YouTube