Light At The End Of The VB Tunnel

‘Don’t mode me in’. With this famous plea from Larry Tesler (who was working at Xerox PARC with Alan Kay) in 1981, Smalltalk was launched onto the public via a series of articles in the magazine Byte. What Tesler was referring to was the way computer programs of the time worked. In order to edit a file, you had to exit from, say, the ‘run’ mode of the computer and start the ‘edit’ mode. There were no windows, no bit oriented screens, not even a mouse. In the classic August 1981 issue of Byte, the word ‘mouse’ was in quotes – no one had used a ‘mouse’ before. The computer world outside Xerox PARC was slow, modal, largely mainframe and IBM was God.

In one way Smalltalk hasn’t been as successful as its founder, Alan Kay hoped: it’s a minor language little used, at least commercially. But in another way, it has succeeded beyond Kay’s wildest dreams. The desktop that we all use these days, whether it’s Windows, Mac OS X or Linux, is based around Kay’s original concepts. Even many of today’s languages incorporate object-oriented ideas, though I very much appreciate Kay’s derisory comment on C++: “I invented the term Object-Oriented, and I can tell you I did not have C++ in mind”.

But there’s another mode that still exists and is increasingly a barrier to efficient use of information. I’m not quite sure what the proper term is, but I’ll call it ‘data islands’. These data islands occurs when there’s some data in one place and you need to combine it with data in another. Suppose you want the latitude and longitudes of all cities with populations greater than 250000. I did want this information some time ago and found it quite difficult to get – at least without paying some cash.

What I ended up doing was downloading some Web pages, located via Google, and parsing the HTML using a Perl script (lots of regular expressions), uploading the resulting data into a Visual Basic program and then writing a simple query so that I could use the resulting database in my program. It wasn’t very efficient and it took me about two days all in all to do it. That’s not good going for such a simple problem.

Stating the problem might be simple: I have some data over there in one format and I want it over here in another format. But finding an easy solution isn’t. What’s needed is a ‘modeless’ data approach.

A couple of months ago, I wrote a piece called The Strange Death of Visual Basic in which I commented on the lack of anything that made me think “Yes! That’s why VB is there!”. That was before the latest Microsoft Professional Developer Conference (PDC). Hidden deep within the vast amount of propaganda, damned propaganda and ‘stuff’ about Vista was some really quite good information on what will be in the next-but-one version of Visual Basic - that is, Visual Basic 9.

In truth, it’s actually quite easy to sift out the marketing junk in a PDC. If the thing you are interested in has a good old fashioned version number – here 9 – instead of a marketing slogan: “ Vista: forward to the future!!” – then you are probably going to get some good info. And so it turned out.

In short, VB 9 looks like what the guys who wrote VB .NET wanted but didn’t have time to do. There’s normally a dilemma like this in any substantial software project. You want to do a whole raft of really neat stuff, but you must ship sometime before the millennium/revolution occurs. The world is littered with failed software projects that were wonderful on paper but didn’t somehow make it. Remember the legendary Taligent Framework?

One of the key features of VB 9 is LINQ or Language Integrated Query. I won’t bore you with the precise syntax of LINQ, but it does allow you to naturally embed SQL queries in Visual Basic and get data from a variety of sources. That’s going to be vastly superior to the current clunky ADO stuff.

Another feature that I came across was function closures – ‘nested procedures’. A closure takes as its lexical context, the surrounding function’s variables. This is exactly the type of call that would have helped some of the ‘orphaned’ Visual Basic users I wrote about previously. Now, I’m not sure how this will help in getting me out of data islands, but it’s getting one step closer to a workable functional language, which itself is very useful in handling arbitrary streams of data and in rapid application development (RAD).

As I mentioned above, with the construction of a new language like VB .NET – let’s call it VB 7 for clarity - it isn’t possible to put everything that you want into the first release. It isn’t even possible to get highly desirable things like edit-and-continue which were in VB 6. So in some areas, VB7 has less functionality than in VB6. VB 8 (to be released real-soon-now, honest), fixes some of these omissions and adds a few more RAD tools like the My namespace. Though how useful this is remains to be seen.

So does VB 9 get closer to getting me out of ‘data islands’? From first sight, yes it does get me at least some of the way. I can get a file or HTML page using the My technology and query the data from it using LINQ. But what I can’t do (as of the published functionality of VB 9) is parse the data easily. While I absolutely didn’t invent regular expressions (before I was born, I think), I’m very tempted to follow Alan Kay and say that “.NET’s regular expressions weren’t what I was thinking of …”. As of today, it really is easier to write a separate Perl script with regular expression parsing than use VB .NET’s apologies for the things.

Still, I’ll take what’s offered in VB 9 with both hands. If the stuff in VB 9 lives up to expectations, I might be able to get enthusiastic about using VB again. In my view, VB has to be a RAD system or it’s nothing but a verbose version of C# or Java.

I think there’s a glimmering of light at the end of the Visual Basic tunnel.

October 2005