Date: May 2001
From: Simon St. Laurent
Subject: VB.NET: Too much too fast?
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
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.
Return to: Ron's VB Forum