What's in a Name?

Readers debate whether Visual Basic .NET needs to drop Basic from its name.

• By Readers of Visual Studio Magazine
• 06/01/2005

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

What's in a Name?
I read Tim Patrick's Guest Opinion, "Basic Doesn't Fit VB.NET" [January 2005], and I was actually a bit disturbed. I must disagree with Patrick—we don't need (yet) another name for Visual Basic. In fact, what we need is to stop these silly naming games that go on in our industry. The confluence of names we have is simply mind-boggling. We get a new name with every new release of a product, yet the products are not so radically different that they warrant new names. It's just another way to confuse members of our community and the experts at the forefront.

At the end of the day, Visual Basic is still Basic. The foundation and elements of the Basic programming language are still the same as it was almost 30 years ago when I programmed with it on my CP/M-based and TRS-80 computers. Over time, Basic has evolved and grown with the latest technologies, and because of that, it has had staying power and continues with its enormously successful history. It is quite miraculous that for a whole generation, the Basic programming language has grown and continued to flourish because Microsoft has been able to adapt it and keep it on the leading edge with every generation of its software.

At my company, we set up projects to develop applications in Java and XML because we're told these are the technologies of the future, and you must develop with them or else you're just not "with it." We had at least one high-profile, notable .NET project that lost its funding and no longer exists. It's a sign of the times—many corporations now develop according to what the industry would have them believe is the right way to do their software development, as opposed to what we know works, is robust, is stable, has a high value, is highly productive, and provides the highest benefit/cost with the lowest amount of risk. In most businesses, these objectives are "basic," yet, because Java, XML, and a slew of other whiz-bang technologies grace the cover of magazines every week, most corporate software business units feel a need to follow the crowd and ignore these basic objectives.

I'm a sole developer supporting about 50 users and their interaction with about 20 "platinum customers." My tools of choice: Visual Basic 6, ODBC, VBA, and Excel. While the armies of developers take months to make the slightest bit of progress, I turn around robust, high-value "applets" in hours and days. These applets utilize data from our corporate databases around the world and extract information from our internal and external corporate and vendor Web sites. Don't let me forget to highlight that most of these are server-based, automated tasks, which run on a Windows XP server.

Should VB6 include the latest and niftiest enhancements to put it on par with C++, C#, Java, or any other language du jour? Absolutely not. Visual Basic is the Swiss Army knife of development languages; it always has been and continues to be. Eventually, maybe I'll even get around to delving into VB.NET, but from what I've seen, it's really a bastardization of Visual Basic trying to make it into something that it was never intended to be.

Over time, we've seen programming languages come and go. The one that has been there since the beginning, has always provided the programming necessities, and since version 5, has provided the enterprise capabilities, robustness, and performance to put it on par with the "best available" development languages and environments is Visual Basic.

Here's my vote for Visual Basic 7.

Correction
VSM ran an incorrect phone number for Red Brook Software in the product review of WiredNav 2.0 [First Looks, "Show Users Complex Data," March 2005]. The correct phone number is 518-248-3450. We regret the error.