I hadn't realized the scope of the changes in Visual Basic.NET. It looks like it'll be a rougher transition than usual, at least if InfoWorld's got it right: maybe Microsoft is doing too much too fast for once.

Many developers tend to dislike change since it almost invariably requires learning a new set of programming skills. To take two examples from relatively recent history, long after the transition from DOS to Windows was a fait accompli, some developers were still hotly debating the relative merits of a command line interface versus a windowing interface. When 32-bit Windows was introduced, developers heatedly discussed whether Microsoft really had to make the integer a 32-bit data type.

In view of this desire that things remain more or less the same, and given the resistance that has met even fairly trivial changes, it is not surprising that many Visual Basic programmers are up in arms about the extensive changes that Microsoft is making to the next version of the Visual Basic language, Visual Basic.NET. In fact, the sentiment is widespread that, in the words of one VB programmer, Microsoft has "thrown out everything and used the Visual Basic label on a new language."

It is true that the scope of the changes to Visual Basic is very substantial. So much so that, although Microsoft is providing a porting tool with Visual Studio.NET, my own recommendation would be for those who have code in VB6 or earlier versions to continue using them, and to use VB.NET for new projects.

I would stop well short of the conclusion that Microsoft has "thrown out everything and used the label on a new language," however. In fact, many of the traditional language elements have been retained in Visual Basic.NET, even though they are now merely wrappers to methods in the .NET Base Class Library. But the point is that Microsoft has tried to retain the features that VB programmers have come to commmonly use and rely on if it is at all possible.

This commitment to compatibility if at all possible is evident in Microsoft's recent decision to reverse three changes to the language (the behavior of Boolean True when converted to a number, the number of array elements created when an array is dimensioned, and the use of separate operators for bitwise and logical operations, as well as a new order of evaluation of logical expressions) and to restore VB6 and earlier behavior.

This is not the first time that Visual Basic has undergone a complete rewrite or that the paradigm for programming with VB has undergone a significant transformation. VB4, which added classes and limited object orientation, also was a from-the-ground-up rewrite of Visual Basic that abandoned a significant portion of VB1-VB3 technology. And VB4 met with a reception very similar to the one that awaits VB.NET: wild enthusiasm from some quarters (including myself and most of the VB developers I know), a certain element of fear and trepidation from the majority, and rejection from a minority who felt that the language had been changed beyond recognition and that Microsoft had just made upgrading too difficult.

Interestingly, as an aside, the changes to the language most strongly affect very advanced VB programmers. In particular, the undocumented pointer functions have been completely removed from the language so that most of the programming tricks advanced programmers used are now unavailable or will work differently than under previous versions of VB. But these same advanced programmers, whom you would expect to be most put out by the language changes, are probably the group most eagerly embracing VB.NET. This is largely because they feel that, although they've lost power in some areas, they've more than gained it back in others.

In many respects, though, the extent to which VB is changing really isn't the point. The real issue, I think, is why Microsoft made the changes in the first place and whether their reasons are sufficiently compelling for the majority of VB developers to want to follow.

So much attention is focused on .NET as well as on Microsoft's newest language, C#, that it almost seems as if VB is an unwilling participant on the .NET platform, a development environment that was dragged along only because it is the most widely used programming language in the world today. According to this view, the "purity" of VB was violated in favor of such things as a common language runtime, a common type system, unified garbage collection, and the ability to access all of the services provided by the Base Class Library and the Common Language Runtime. As a result, some have argued that VB is a legacy language that will simply lose appeal and whither away.

I don't agree with this position, however. Above all, I don't agree that the .NET platform can be seen as simply an "imposition from without" that was forced on Visual Basic. Instead, VB.NET strikes me as owing its inspiration at least as much (if not more) to the dynamics of VB's own development as to Microsoft's decision to champion the broader .NET platform for ongoing development. The plain fact is that VB was becoming dated as a language, that there was a growing disparity between its original conception and its current usage, that it had lost its original vision, and that as a result its future was uncertain.

It's important to remember that VB was originally introduced as a kind of Windows "drawing program:" You used drag-and-drop techniques to "draw" a user interface (i.e., a form or window with its controls) and then clicked on controls to access event handlers that you could code. With VB, anyone could write a simple Windows program in seconds, and an experienced VB programmer could write a fairly sophisticated program in a couple of hours. In contrast, at the point that VB came out, many experienced C programmers felt that it took a year for the average C programmer to make the transition to C programming for Windows before he or she could write any real production code at all. So VB 1.0 really was a revolutionary product (even though it didn't even begin to realize its promise until VB2 was introduced).

Through six versions, though, VB remained a kind of drawing program for Windows applications. In fact, that characterization is far more true of VB6 than it even was of the original release of VB. Yet, the overwhelming majority of VB programmers no longer writes Windows applications or Windows front ends but instead uses it primarily for component development. VB is now being used for purposes that its original designers hadn't forseen, and for which it really doesn't offer particularly great support.

This is problemmatic in two respects. First, it means that the existing base of VB developers have a good deal of difficulty in developing some types of technology. For instance, VB6 is not a good tool to use for Web development (except for middle-tier components). All of the attempts to integrate it with ASP, for instance, have been abject failures. Second, Microsoft has traditionally championed the cause of lowering the barrier to entry into the world of programming for non-programmers, and VB has been its flagship product for doing just that. But in recent years, particularly as attention has shifted to the Web and as most new non-programmers have been interested primarily in developing Web applications, VB has lost much of its appeal.

From this perspective, VB.NET represents an attempt to revitalize Visual Basic and to make it once again the broadly based programming language of the future, as well as the tool that offers the greatest ease of use to new programmers. And although I think there are going to be some rough edges to the transition, I personally find Microsoft's reasoning compelling and the new version of Visual Basic exciting. Despite a good deal of grumbling, I believe most VB programmers will eventually feel the same way.

Ron

Return to: Ron's VB Forum