07 April 2005

I was asked a couple of times today on my views in the great VB6 support debate. I got a few emails about this as well. Just in case you haven't heard of it (for some reason CNN, the BBC and the other big news organisations felt other global matters carried more weight than a discussion about VB6 - can't think why), here's the deal. At the end of this very month, Microsoft will end free support for Visual Basic 6. Now to many people that's a bad thing. In fact, to many people it's a terrible thing, serious enough to prompt around 100 MVP's to get together a petition to keep Visual Basic 6 (or "classic VB" to give it its new retro-cool moniker) alive. The argument is a fair one. At its height there were literally millions of "classic" Visual Basic programmers out there, so it's a fair bet that hundreds of millions of dollars, maybe billions, were spent in developing and researching software produced with Visual Basic. Likewise it's a fair bet to assume that a great many of these projects are still around, and still being supported. In fact, you could even go so far as to surmise (correctly) that there are still a lot of classic Visual Basic programmers out there, and probably more than a handful of new projects based in the technology. For Microsoft to just kill the product off would be foolish, selfish, and thoughtless. At least that's how the argument goes. There's a fundamental flaw in the argument though. Microsoft are not killing off Visual Basic, and they are not ending all support for it. When you buy Visual Studio 6.0 you get a certain number of "free" calls to Microsoft Support should you get stuck. That's the thing that's ending. From the end of this month, if you want to call up Microsoft support and ask them a question, it will cost you. You can either get a support contract to cover this cost, or pay per call fees. This will continue until 2008 when all support for the product will end. Now, I don't know about the rest of the community, but I tend to find that spending a while in a fantastic online tool called "Google" lets me solve most every problem I ever come up against while coding. The fact that Google Groups actually has an archive of every major newsgroup out there going back more than 10 years is also a bit of a bonus. Given "classic" VB's age, there's a bloody good chance that if you run up against a problem, you'll be able to find the solution using Google Groups, and it won't cost you a penny. So, even when Microsoft do end all support for the product in 3 years time, the "classic" bunch still aren't out in the cold. By my reckoning then there's about 100 MVP's out there who really need  to do just a teeny bit more research before they scramble for their ThinkGeek Enchanted T-Shirts of Indignation + 10. But, VB is dying as far as Microsoft are concerned. In 2008 they won't help you out if you get stuck and so as far as they are concerned it's no longer used in production environments. Is this a bad thing? I guess this is where the questions I got asked today stemmed from. After all I was "Mr VB", the guy with the loony toons braces (suspenders if you are American) on those bright red books that flooded bookstores and cubes around the world. Surely I would leap to the defence of a tool that meant so much to me? The short answer is "not bloody likely". Here's the deal guys. In 1990-something-or-other I was on a panel of esteemed types from Microsoft, and consultants TMS at the first ever VBUG national conference. Visual Basic 4 had just come out, bringing with it "classes". A chap in the audience asked the question "which would you use today - VB3, or VB4?". I sparked a furious debate in answering that question with a succinct "VB3". VB4's class support just sucked. It was a half assed attempt to introduce something which to the uneducated looked a bit like object orientation, but really wasn't. That half assed attempt stuck with VB all the way into VB6, growing like some nasty malignant lump in your armpit. It wasn't pleasant, it made other people laugh at you, and it generally wasn't at all in line with what the rest of the world (Smalltalk, Delphi, Java, C++) were doing from an OO sense. It was silly. With VB.NET, the core language changed in order to accomodate proper full blown object oriented programming, and that was the best thing that ever happened to Visual Basic in my opinion. At last VB developers could draw on the mass of research out there in whitepapers, articles and books on the best practices surrounding software development. You could implement patterns elegantly, hold intelligent conversations with other OO programmers and generally approach problems "the right way". As if that wasn't enough, while the rest of the world was exploring the delights of byte code (intermediate language if you like), just in time compilers, optimizing compilers and so forth, we were still lumbered with a hideous abhoration of science that was a compiler, but wasn't, but was, kinda, if you look at it this way, under a certain light, we think. VB started life interpreted and as it grew it just couldn't really shake that off, no matter what Microsoft did. At the end of its life it kinda was compiled but the environment then wasn't aware of 64 bit processors, oodles of memory, and hyperthreaded pentiums. Today's solutions based in .NET are. There are tests out there that show that .NET code can run faster than C++ code compiled with the out of the box compiler settings, simply by virtue of the fact that the runtime is able to optimize the compilation, at runtime, to best fit the current host architecture. That's a good thing. That's a very very good thing. Why on earth would you want to run a legacy runtime in a modern environment? That's like grabbing the nearest copy of QuickBasic and churning out a nice little DOS app to fit in with your enterprise's current SOA plans. It won't work. It won't make sense. It will cripple you in the future. Then there's the other more serious issues, like the fact that there isn't a single data type in "classic" VB that could hold the amount of data we work with today on a daily basis. How about the fact that "classic" VB just doesn't play well in true multi-tasking environments. What about the slight issue that as time goes by the available resources out there to hire to support your ageing, or perhaps in development, classic based applications will grow smaller and smaller, and costlier and costlier. Surely that's not a good position to be in if you are supporting production is it? Oh, sorry sir, we can't process your critical line of business applications bugs because we can't find anyone that still knows how to program in classic VB. Isn't that the problem we faced with the Millenium farce and the grey haired Cobol crew? But you know all this is semantic, semi religious debate. I hinted at the big problem earlier. Hardware. We live in a world today where my handheld games console outperforms the last PC I coded classic VB on. We live in a world of multi-terrabyte disk arrays, grid computing, multi-processor 64 bit machines, memory measured in gigabytes. This is not an environment Vb was ever designed to run in. I had to buy memory for my dad's ageing PC a while back and it cost three times what memory normally costs, because it's obselete. In 3 years time, if Microsoft were to continue support for VB6 what do you think the result would be? How about an inundation of phone calls from people screaming that their classic VB app suddenly fails to run on a  12 Ghz quad processor desktop with a FireWire 6000 disk array? Continuing support does nothing to change the fact that the face of computing is changing and the time will soon come where classic VB apps just wont run any more. Killing it off then is the sensible thing to do since it forces people to migrate apps before that happens, thus preventing thousands of businesses (and 100 MVPs obviously) from suddenly finding themselves royally screwed by circumstances outside Microsoft's control. But then again, perhaps the view should be that legacy hardware production should continue as well. Hell, there were a  few million Apple IIs in use in businesses at one point, perhaps we need a petition to get Microsoft to include an Apple II hardware emulation layer in Longhorn? I don't want to waffle any more. The point I'm trying to make here is that classic VB is a legacy system. It was designed to solve a different set of problems, in a very different world to the one we live in today. If you want to develop with Classic VB then Google's there to support you. If you want someone on the end of a phone to answer your questions then go and grab a copy of REALBasic - it's faster and slicker than classic VB, but still compatible. VB was great for it's time, and we owe it a great deal. But for god's sake put the animal out of it's misery. Doing so is the only right and humane thing to do.   7:36:36 PM