It's taken me a while to figure it out conceptually, but Visual Basic 6.0 really is analogous to those quick console applications "real" programmers like to make. When a traditional C++ programmer might slap together something without a user interface to accomplish a task that'd be quicker to code than to do with other tools, not worrying about whether his/her code is exactly to spec, Windows programmers will use VB.

VB hacks are weird things to see. Logic is tied to the GUI, a huge traditional taboo, and layout is about as ugly as it could get. Everything's named the default,Textbox1 and List3, making it more difficult for anyone to follow what's going on.

But the point is that it works, and works quickly. Click, drag, slap in a few lines of code, and you've made an app that's just as accessible to users addicted to GUIs as command-line apps are to "real power users".

Though VB support is going to start going away in a few years, it's still a great engine for creating useful, accessible, and horribly ugly applications that don't require typing "foo --help" to understand and get working.

You can still make "real" apps in VB, but it's difficult. Even more difficult is making a good "GUI + logic" app (where the two are separated) the right way with a team of true VB programmers. All these slapdash bad habits are going to make their way into your code, and at some point you're just going to have to throw your hands up and accept it. Remember, the idea of separating logic from UI, an essential programming point, is a completely foreign concept to the traditional VB programmer. Good luck. ;^)

Of course there's the option of creating all of your logic in one COM or .NET object and use VB solely for the UI. This is the right way to do things, even if managers don't always understand why. In .NET, the Windows Forms classes should be used to create UI and are basically supposed to fill the role VB 6.0 once provided for Windows programmers. But VB.NET isn't VB 6.0, and there are going to be some growing pains. Having separate logic/UI teams are one good way to avoid headaches.