Dermot Hogan ponders on the future of Visual Basic and decides that the tea-leaves are giving strange and dangerous messages …

One of the things that’s become clear to me in my wanderings through the Visual Basic .NET vs. Visual Basic 6 controversy is that there are a lot of annoyed people out there. Very annoyed, very pissed off - and with a very large code-base to support. A very large ORPHANED code base.

If, like me, you are a small-scale user of VB, the argument between the VB6 fraternity and users of .NET may seem arcane. In my opinion, VB .NET is clearly a better language: it’s got vastly better error handling and a much nicer development tool in Visual Studio 2003. It’s also object-oriented (if you’re into that sort of thing) and best of all, from my point of view, it’s multithreaded.

Over the last two years I have written, from scratch, a decent sized VB .NET application which is multithreaded and talks to a real-time system via a fast USB2 link. But, in the course of doing this, I’ve begun to have my doubts. And gradually, I’ve come to the conclusion that if I was starting again I wouldn’t use VB .NET. I’ll explain why below, but first let’s look at the guys who have a real problem. Currently, I’ve got a nice shiny program with a few thousand lines of code. But wait a minute - what if I’d got 100,000+ lines of code, all written in VB 6? I think I’d be in trouble …

Even if you are utterly indifferent to the plight of VB6 users (“serves ‘em right for using a stupid language!”) you might consider this: if Microsoft is treating a loyal (and presumably profitable) customer base as if they had an unpleasant medical condition what might it do in future? With this thought in mind, do you really want to commit yourself (and your business) to writing a huge application in C#? It certainly set me thinking….

The Problem

If you’ve built your business on VB6 over the last decade or so, you’ll have had to put up with Microsoft changing the rules from time to time. In going from VB3 to VB4, Microsoft introduced 32-bit address spaces, for example – a fairly substantial change. There’s nothing too wrong with that provided you don’t go too far. If nobody changed anything we would all still be using code full of lines with numbers on.

But in going from VB6 to VB .NET Microsoft did far more than that. It re-wrote the language: VB .NET is, in essence, a totally new language. It bears some superficial resemblance to VB6, but underneath it is entirely predicated on the .NET Common Language Runtime (CLR) and its data types; and at compile time, you have to use the .NET framework.

Now, the change to using the .NET CLR is substantial, but manageable. Changing the VB Integer data type from 16-bits to 32-bits is radical, but with a good editor and some decent testing, you can cope. There are other similar changes – mainly small, possibly annoying, but generally manageable. But what isn’t manageable is where Microsoft has thrown out language constructs – like the good old GOSUB. This little story bears some examination.

You might think, as I initially did having never once had cause to use it, that it was about time that GOSUB was given the boot. But it turns out that on closer inspection (reading the manual, that is) that GOSUB is not quite what it seems. With a VB6 GOSUB, the lexical scope of the GOSUB is that of the surrounding FUNCTION or SUB. So you can access variables quickly within a routine without having to pass them as parameters. In other words, it’s a “nested function”. Now this isn’t very common, but there are languages which do allow you to do this – ALGOL68 and Pascal being two that I’m familiar with, and I’m sure there are several more. But one language that you cannot do this in is ANSI C. And that has followed into its descendents – C++ and C#, though the GNU C compiler family now has an extension to allow nested function declarations.

The reason why allowing procedures to be declared with procedures has gone out of fashion is mainly, I suspect, due to the dominance of C. The downside is that the technique requires a more complicated compiler, has slightly more overhead associated with it and just possibly may be trickier to debug. But it does have it’s uses – I’ve used it myself in some ALGOL68 programs.

Anyway, the point here is that if you’ve got hundreds of thousands of lines of code that use GOSUB, then you are well and truly in deep… trouble. There is no simple way of converting your code and the Microsoft-supplied conversion tool just doesn’t do anything apart from tell you that you can’t. So there!

Now, let’s suppose you are the proud owner of several hundred thousand lines of VB6 code which use this feature and you’ve built a successful business on your application, employing some dozens of programmers and associated staff. Oh yes – and Microsoft has said that it will cease ALL support –even paid support - from sometime in 2008? Well, as someone once said: it’s an interesting intellectual problem.

But that’s not all, there’s more. Just consider the problem of converting vast chunks of procedural code into something that is OO based (and with VB .NET you MUST be OO based even if you generally avoid using OO like the plague). That is not simple. It can be bad enough to convert an application which is 1000 lines long (I had to give up on one of mine – the Microsoft porting tool was useless). But 100,000 lines or more? Building the pyramids would be quicker.

Solutions

Fundamentally, Microsoft has said that, come hell or high water, VB6 will cease to exist as far as it is concerned sometime in 2008. Additionally, it seems that Microsoft is not going to enhance the porting tool or add new language features to VB .NET. So, if you have the “interesting intellectual problem” which I mentioned above, what are you going to do?

One language that does support both object oriented programming and procedural methods is Delphi. In addition, being Pascal based, it also handles the GOSUB problem nicely. And there are tools out there that will convert from VB6 to Delphi. Borland might be beginning to smile again after a long period in Microsoft’s shadow.

Another alternative might be to use VB6 a lookalike such as REALbasic. The problem here though might be jumping from the frying pan into the fire. Betting your future on a small software vendor having been burnt by a large one may not be the best, or most tempting, strategy.

Or you could re-write the whole shooting match in VB .NET. But if you are going to do that why chose VB? C# seems to be the way Microsoft is pushing things and I’ve certainly seen no real advantage in using VB .NET over C#.

The last option is to do nothing. VB6 programs will continue to function in Windows XP for some time to come. But in the long run? In the long run, you’ll certainly end up proving Keynes’ dictum: in the long run, we’re all dead.

The Future

I mentioned above that I’d used VB .NET for a reasonable sized project. Over a period of about two years I’ve learnt what works well and what doesn’t. Briefly, the good bits are the error handling, multithreading, delegates and the .NET Framework. Yes, I know the Framework can be a real pain – but overall, it’s improved my productivity considerably. The bad bits are the lack of unsigned type support and interfacing to unmanaged memory. The former is just annoying and is being fixed in the upcoming Visual Studio 2005 release. The latter is simply grim. The words “major surgery” and “no anaesthetic” come to mind.

But enough of that. What gradually dawned on me as I progressed through my project was that there was little or no advantage to using Visual Basic .NET over C#. Some parts of the project were written in C# and quite a large portion - the real-time microcontroller - was written in plain old ANSI C. But looking back, I genuinely can’t think of a single significant plus that made me think “Yes! That’s why Visual Basic is there!”. In fact there was a downside for my application – switching my brain between thinking in VB and thinking in C/C# could often be quite difficult. Especially late at night.

Microsoft seems to be intent on wrecking the Visual Basic world. Before .NET, There was a clear advantage to using VB6 over, say, C++. True, you couldn’t do as many things in VB6 as in C++, but what you could do was safe, fast and hence productive. But now, there is really very little difference between C# and VB .NET. Indeed, in C# you can do a bit more than in VB .NET. As well as the insult of not improving VB as a rapid application development language, there’s the strong insult of abandoning a loyal and enthusiastic customer base.

Is there a future for Visual Basic? I’m beginning to think that there isn’t.

Dr. Dermot Hogan (Bitwise Technical Editor) formerly wrote the Visual Basic programming column for PC Plus magazine in the UK. A specialist in realtime trading technologies, he has managed and developed global risk management systems for major international banks and financial institutions. Dermot holds a Ph.D in physics from the University of Cambridge. In addition to VB, he has programmed in C, C++, LISP, ALGOL68, Perl and other languages far too numerous to mention.

July 2005