Bruce McKinney's Hardcore Visual Basic

 

 

 

 

 

 

Hardcore Visual Basic

A Hardcore Declaration of Independence

When in the course of human events it becomes necessary for a programmer to dissolve the ties that bind him to a language, a decent respect for the opinions of others requires that he should declare the causes that impel him to the separation.

I hold these truths to be self-evident, that all programmers are endowed with certain inalienable rights, that among these are convenient access to operating system features, reasonable compatibility of old code, and use of modern programming techniques. That to secure these rights, computer languages are developed. That whenever a language becomes destructive of these ends, it is the right of the customers to abandon that language and seek another that seems more likely to create efficient, bug-free programs within reasonable development times.

Prudence, indeed, will dictate that languages long established should not be changed for light and transient causes; and accordingly experience has shown that programmers are more disposed to suffer, while limitations are sufferable, than to abandon the languages to which they are accustomed. But when a long train of disappointments evinces a design to reduce them to gross hacks and workarounds, it is their right and duty to throw off such languages. Such has been impatient sufferance of this Visual Basic programmer; and such is now the necessity which constrains him to alter his choice of languages. To prove this, let facts be submitted to a candid world.

In other words, I've had it. With the release of Visual Basic 6, I must terminate my relationship with Visual Basic and, unfortunately, my commitment to the loyal readers of the first and second editions of my book, Hardcore Visual Basic.

Now some of my loyal readers may point out that I already attempted to burn my bridges. The second edition of my book had some criticisms that were so specific that some of my best sources on the Visual Basic team started to dry up. I would have had a hard time doing another edition even if I wanted to. But I didn't. A blurb at the back of the book claimed that perhaps I'd had "enough of Visual Basic for a while and wouldn't be writing another book anytime soon."

Well, it's not so easy to abandon a language when you've developed a reputation as an expert. The mail keeps coming in. Bug reports pile up. Related offers and proposals arrive from time to time. If you know the language so well you sometimes dream in it, you might be tempted to give it just one more try. I was so tempted. This is the story of that one last try and its fiery end.

It's also an attempt to have the last word, in terms of flames, apologies, bug fixes, advice, and a few bits of technical information. Finally, it will fill holes for a bunch of new readers who suddenly, through no fault of their own, find themselves the owners of the text of my book (through the MSDN CD provided with VB6) but not the code. This tale will be instructive even to those who are still disposed (or required) to suffer the limitations of Visual Basic in order to enjoy its admitted benefits.

How a visit to Delphi confirmed my preference for and disappointment in Visual Basic
In the Fall of 1997 I took a little trip to the other side and visited
Delphi. The original Turbo Pascal was my first compiled language way back in 1983. As my discontent with Visual Basic grew, I decided to return to Pascal to see how it had grown into Delphi. You can see the results of my experiment in the April, 1998 issue of Delphi Informant. Since few readers of this article subscribe to that magazine, I'll summarize the most important point:

Visual Basic makes the easy things easier; Delphi makes the hard things easier.

If you know the language so well you sometimes dream in it, you might be tempted to give it just one more try.

 

My Delphi Informant article reimplemented the file notification server described in Chapter 11, "File Notification," page 640. Both versions of the Notify server are functionally equivalent, but there's quite a difference in their implementation. On the client side, the code required to hook up a Notify server is much simpler in Visual Basic. On the implementation side, VB has the advantage in how it defines classes and interfaces. The actual storage of the notification data was not difficult in either language. But the Delphi implementation turned out to have a strong advantage in how it started or closed down the server.

In Visual Basic there's no documented way to count how many clients are connected or to determine when the last client unhooks so that you can clean up and shut down. I had to use some API hacks and a complicated reference-counting scheme. A Delphi wizard generates a default message loop for your component, but if it doesn't do what you want, you can replace it—which is what I did. My loop provided a place to wait for notification events and to check the number of clients through the ObjectCount property of Delphi's public ComServer object.

In my Delphi article, I summarized the tradeoffs between the two languages: "VB makes it easier to create and use simple Automation objects. It does this by hiding the details. But once you move to more complex Automation problems, you may find those details aren't as irrelevant as they first seemed; you may want to see and control them. If you're clever enough, you can usually hack your way around VB limitations, but in Delphi you can usually solve the problems without arcane hacks."

That may sound like a win for Delphi, but I actually prefer the Visual Basic model. It's more important to me that the easy stuff be easy. I don't mind hacking the unusual stuff. My problem is when the language Basic fails to come through on its contract. Of course neither Delphi nor VB comes with a written contract, but here's how I interpret their promises based on history, documentation, features, and marketing.

Delphi contract: We will make 80 percent of the grunt work of creating GUI apps and components (COM or otherwise) easy through use of wizards, library functions, and inheritance mechanisms. We'll provide more complicated but standard means to do the other 20 percent of your work.

Visual Basic contract: We will make 95 percent of the grunt work of creating GUI apps and COM components easy by doing it for you in ways that you can't see. You're on your own for the other 5 percent.

Most of Visual Basic is a black box. It works, but you can't tell how except by inference and testing. Delphi is a root-beer-colored box. If you take the time, you can see through the glass darkly to discover how it works and how to extend it.

Given those two contracts, programmers might reasonably choose one or the other. I prefer Visual Basic, however, I no longer believe VB is fulfilling its contract.

Why I became weary of my favorite language
I like Visual Basic because it hides the details. If you've written even the simplest Windows program in C you know that there's a message loop and an incredible amount of other boiler-plate code behind every form before you write a single line of code. With so many languages claiming RAD development features these days, young programmers may not realize how revolutionary Visual Basic was when it first shook the programming world back in 1987.

The original Visual Basic form creation model is my standard for evaluating all new features. I put my test in the form of a True or False statement. "In Visual Basic, using feature X is as easy as creating and using forms." That's the standard set by Visual Basic 1, and it's the standard I expect new features to attain. Let's try it out:

"In Visual Basic, creating controls is as easy as creating forms." True in theory, False in practice. While you could create a UserControl as easily as a form and start adding properties, methods, and events, it wouldn't be a realistic control. You have to use a wizard to delegate the properties and methods. Using wizards is a technique taken from Visual Basic imitators such as Delphi. Visual Basic does not imitate this technique very well since wizards in state-of-the-art programming environments are two way while VB's wizards are mostly one way.

"In Visual Basic, object-oriented programming is as easy as form programming." True at the first level, but increasingly False as your classes start to add advanced features. There are silly flaws in VB's implementation of common object-oriented concepts such as friends and static members, and it remains the only "object-oriented language" with no inheritance or constructors.

"In Visual Basic, creating COM objects is as easy as creating forms." Mostly True. Visual Basic has done an amazing job of hiding COM mechanics. Some Visual Basic programmers complain that VB is too automatic in its generation of GUIDs and management of compatibility. Things can get messy when you run into circular references. Also, delegation requires a lot of handwritten code, even though it's boilerplate that could easily be generated automatically. But the part of COM that VB does, it does well.

"In Visual Basic, creating programs with the latest interface doodads is as easy as creating forms." Absolutely False. The controls that implement modern features like treeviews, listviews, toolbars, coolbars, and combo boxes with images are poorly designed with inadequate property pages. It's still extremely difficult to put images on menus. Even features as pervasive as small icons are difficult to handle. You have to be a guru to navigate the namespace or to create file viewers or shell extensions. We're left far behind in the new trend of coming out with a new COM interface every few weeks. And don't even think about events for the mouse wheel or support for multiple monitors.

"In Visual Basic, using advanced 32-bit operating system features is as easy as creating forms." Mostly False. Visual Basic does a nice job with automatic threading in components, but it doesn't support free threading in clients. You have to go to the operating system for synchronization and memory mapped files. In many ways Visual Basic remains a 31-bit language.

"In Visual Basic, creating collections is as easy as creating forms." Laughably False.

"In Visual Basic, creating DLLs of functions is as easy as using forms." False. Global objects are some sort of sick joke that appears to have been designed by medieval theologians.

"In Visual Basic, is using pointers as easy as using forms?" Wrong question. Nobody could make pointers

 

Better to suffer, while limitations are sufferable, than to abandon the languages to which we are accustomed.

easy, and nobody should have added them to a language that aspires to simplicity. The correct question is, "How do you do the things that other languages do with pointers without pointers?" Java does it, and VB ought to do it. Pointers in Visual Basic are like an automatic transmission on a bicycle.

I could go on with these analogies. Many of the features from VB4 and almost all the features of VB5 and VB6 fail to meet the Form Creation standard of simplicity. Why don't they? I think it's due to a lack of imagination and vision.

Now I know that Visual Basic designers are going to claim that they don't lack vision. They just don't have the same vision I have. My dream for Visual Basic was that it should become a good general-purpose, high-level, object-oriented language. With Visual Basic 4, I thought the language was well on its way to achieving that goal. Versions 5 and 6 have let me down.

I know that Visual Basic is primarily used in the real world as a wrapper for database operations. I also know that Microsoft is trying turn Visual Basic into a Web development language. Neither of those uses interest me. I have nothing against them, but they're not in my book because I don't care.

The way I picture it, most readers of my book spend 80 percent of their day playing alphabets games with SQL, RDO, ADO, OLE DB, Dynamic HTML, ASP, MTS, and a bunch of other acronyms. These readers spend 20 percent of their time doing general purpose tasks to make their data look good. Because Visual Basic isn't a very good general purpose language, they have to read my book to figure out how to do it.

I spend 100 percent of my programming time doing general purpose stuff. The limitations that bug other people 20 percent of the time bug me 100 percent of the time. As a result, I developed a delusion and came to believe that the designers of Visual Basic wanted to make it into a good general purpose language. They never promised this in any way. They never described it as one of their goals. Although some of their actions in version 4 might have reinforced this illusion, there was little evidence in version 5 and nothing in version 6 to support it.

So why did I feel betrayed when they did nothing to improve the language itself? I can only blame myself, but now that I recognize the delusion, I can work on the cure. I have already been through the stages of grief: shock and denial, anger, depression, bargaining, and sadness. I'm still working on the last stage—forgiveness, resolution, and acceptance.

Funny thing is, they're probably right from a financial standpoint. The improvements I want probably aren't going to win any new customers. How are you going to put little fixes like string concatenation in constants in a bulleted list of marketing features? Are potential new customers really going to base their choice on the fact that VB is the only OO language without constructors? Most of us can't quit VB for financial and professional reasons, no matter how frustrated we get. Better to suffer, while limitations are sufferable, than to abandon the languages to which we are accustomed.

Visual Basic designers have chosen to pile more and more doodads on a weak foundation, knowing that doodads, not foundations, sell boxes

 

Visual Basic designers have chosen to pile more and more doodads on a weak foundation, knowing that doodads, not foundations, sell boxes. Perhaps they've made the right choice, but there's a price to be paid. They exchange the respect of their peers for financial success. Unfortunately, a committee can't choose self-respect over profits. The heart of the problem is that there's no one in charge. No one person designs the language. There's no vision because there is no visionary.

The Visual Basic committee must respond to pushing and pulling from all directions. On the one hand, they must coordinate releases with Microsoft Office products because they share the VBA language and some parts of the development environment. On the other hand they must coordinate with other Visual Studio languages because someone on high has declared that Visual Basic is part of Visual Studio even though it has nothing in common with the other languages other than the execrable help viewer. On the third hand, they have to respond to pressure from various operating system technologies such as ADO and various Web technologies. On the fourth hand, they have to respond to users, each of whom has a pet peeve different than the pet peeve of every other user. On the fifth hand, they have divisions among themselves—some disdain language fixes that make for simpler code as "syntactic sugar," while others propose half-baked advanced features like AddressOf.

Sometimes it's easier to give users what they ask for than to figure out what they need. I appreciate the problem, but I don't need a language designed by a focus group.

Next Page   Table of Contents