|
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
|