|By Bob Hendry||
|June 1, 2003 12:00 AM EDT||
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.
|Captain Caveman 06/27/03 09:39:00 AM EDT|
I find it incredible that someone actually admits to being a "VB guru" and goes on to defend the technology without any evidence.
Most VB people I have spoken to know that the technology is poor and that what they are doing is low-tech. The people that really bother me are those that actally think VB is okay.
I say to these people to please, please go and read some books on computer technology. If you cannot read then please sign up to some reading lessons first. Than come back to us.
Bob - if you would like to commission me to write a piece on VB in around 800 words then please don't hesitate to contact me.
|Homey the Clown 06/27/03 09:00:00 AM EDT|
Bob, you still got a mullet? Is that workin' for ya?!
|VBDude 06/27/03 08:42:00 AM EDT|
VB is not evil, Bob, it's just misunderstood.
Anyhoo, I am a VB guru. I rock, dude!
|Bob Hendry 06/26/03 10:30:00 AM EDT|
More detailed technical limitations to VB?
I only had 800 words to work with!
|Charles 07/11/03 09:19:00 AM EDT|
As a programmer with a unix & C background, I would say it's horses for courses.
If you want to spend years writing an operating system, do it in C.
It is possible to write robust and efficient code in VB, you just have to be better at it than your average spotty sixteen year old school leaver.
And whichever way you look at it, it is better than PB.
|Captain Caveman 06/26/03 07:13:00 AM EDT|
I agree with the title of your article. I have recently been introduced to VB after years of Java/C++. However, you do not set out an adequate case against VB. You have two arguments - concurancy problems, and adjusting the application to database changes. These are issues with any multi-user application using a database. As the editor of the site I would expect you to provide the detailed technical limitations to VB. I would enjoy this immensly as I am currently using VB and I need to vent a great deal of frustration.
|Ernesto Cardenas 06/12/03 08:55:00 AM EDT|
Yeah, there are a lot of guys that know VB and call themselves programmers.
But PB wasn't better, because the DataWindow was so tied to the DB. You allway fall in the temptation of use it. It worked, yes. But this applications we're monolithic, very difficult to implement in a multi-tier architecture. No 3 layers no nlayers... no disconnected, no optimistic.... no Web Components.
VB regardless of the trap of DataBinding, was more able to develop components, disconnected applications.... Business Logic without interface... etc...
Don't blame the tool, blame the teachers....
DataWindow was a tool that needed a lot of changes in order to adjust to n-tier and Internet....
- Where Are RIA Technologies Headed in 2008?
- PowerBuilder History - How Did It Evolve?
- Creation and Consumption of Web Services with PowerBuilder
- Cloud People: A Who's Who of Cloud Computing
- DDDW Tips and Tricks
- Working with SOA & Web Services in PowerBuilder
- Cloud Expo 2011 East To Attract 10,000 Delegates and 200 Exhibitors
- Dynamically Creating DataWindow Objects
- OLE - Extending the Capabilities of PowerBuilder
- DataWindow.NET How To: Data Entry Form
- Custom Common Dialogs Using SetWindowsHookEx
- Cloud Expo and The End of Tech Recession
- Solutions for Optimizing ASP.NET Applications
- Dynamic SQL
- Office 2003 Toolbar: A New Look For Your Old PowerBuilder App