Over the past six months I have been working with programmers with Visual Basic backgrounds. Usually this is a recipe for disaster - like getting dog people and cat people in the same room. With the .NET languages in full swing, and PowerBuilder transformed into a language we would not have recognized only three years ago, this whole thing about PowerBuilder versus Visual Basic has become outmoded and irrelevant. Now I would like to take one parting shot at the worst client/server language ever invented - Visual Basic.

Over my cube wall I can sometimes hear debates about using "data bound" versus "non-data bound" controls. I've often heard murmurs of such discussions but never paid them much mind. Take a quick peek at Visual Basic-related newsgroups and you'll see them clogged with questions on how to bind database columns to this-and-that control and so on. They start with, "Can anyone tell me how to bind my DataGrid to an ADO control?" "Why yes! First you build a...." The thread ends with "Thank you. You rock dude!"

No dude, you don't rock. Binding data to controls is a one-way ticket to hell. Visual Basic should never have allowed this concept. I can only draw the conclusion that Visual Basic is evil.

In the beginning, Visual Basic allowed people to take a programming class in college and call themselves programmers. Drunk with the debauchery of the dot-com era, herds of nontechnical people learned Visual Basic so they could cash in on the large salaries of the day. This is how it worked. First, the professor shows the class how to drag-and-drop controls on the form to demonstrate how simple programming really is. After a remedial session on looping constructs and decision blocks, it's time to talk databases. Almost nothing is mentioned about relational, database design, or implementation. Now it's time to connect the database to the controls. With a few simple drag-and-drops, or by using a data wizard, the data from the database columns magically appears in controls such as a TextBox or DataGrid. The whole class beams with their accomplishment. High fives all around. No dude, you don't rock.

Better yet, the class is introduced to the Visual Basic data environment - set up the connection, add a Command class or two, and then drag this beautiful creation onto the form. The data environment will even create all the necessary TextBoxes for you. Another scenario is for the class to build a Web site using Web classes. Not only are you a programmer, but a Web developer. Yaaaa-hooo!

Why are data binding, data environment, and various associated wizards so evil? They limit you, the programmer. They prevent you from becoming better, making more money, and getting promotions. You don't know what happens behind the scenes, so when something goes wrong, you're so lost. Also, data binding locks you in - when you have to go beyond its abilities (which happens in all but the most trivial apps), it's incredibly difficult to break through its limits.

What are the practical problems you'll encounter with data binding? The first one you're likely to run into very quickly is the inability to exercise data concurrency control. Say you have two users accessing the same row of data. This is difficult enough to control with ADO - with data binding it's nearly impossible. The second, much more difficult problem to resolve, you'll run into later, when the product has already been designed and written. This is the inability of the data binding engine to adjust itself to your database situation. The data binding engine does not know where your database is, whether the pipe the data is traveling through is high or low bandwidth.

As a PowerBuilder programmer, I could not care less about Visual Basic. The problem I have is when organizations realize that Visual Basic was designed for toy applications. At this point they move on to more robust tools, like PowerBuilder. Then the swarms of Visual Basic programmers scream about the inadequacies of PowerBuilder. I often hear "PowerBuilder does not support data binding!" or "This was so much easier in Visual Basic." Pass me the tissues. You should have never learned Visual Basic in the first place.

With pure client/server languages in the twilight of their careers, existing Visual Basic applications will either be migrated to VB.NET or left to die on the vine. Rest in peace Visual Basic; I will not miss you.