Language Cleanup

As should be clear by now, moving to the .NET platform entailed some radical changes to the Visual Basic language. On top of the language changes, there were a number of programming model changes (such as the move from Visual Basic forms to .NET Windows Forms) that significantly changed the way that code is written in Visual Basic .NET. Because of the magnitude of the changes necessitated by .NET, it was clear that code from Visual Basic 6.0 would not be 100% forward compatible. Some migration and rewriting would be necessary to get code to compile, and even more would be necessary to fully move it to the .NET way of doing things.

Given this situation, the Visual Basic team decided to take the opportunity to make a few changes in the language that were not required by moving to .NET. Each of the changes was in response to specific feedback or user experiences that the team had gathered over the years , and each was considered by the Visual Basic team to be an improvement to the language when balanced against the cost of additional conversion requirements. For the most part, the changes involved removing support for anachronistic parts of the language. Examples of this would be the Def statements (such as DefInt ) and Gosub . Selected on both feedback and experience, the pieces of the language that were dropped were ones that were rarely used by developers (and in some cases apparently largely forgotten!) and did not provide significant programmer benefits. A few of the other changes corrected quirks , such as changing Wend to the more regular (and grammatical ) End While . Most of these corrections are automatically handled by the migration tool and by the editor (i.e., when the programmer presses Enter after starting a While statement, End While is pasted in automatically).

Probably the most significant change was the redefinition of the Integer and Long types to 32 bits and 64 bits, respectively, and the addition of the 16-bit Short type. The primary problem with a 16-bit Integer type is that the .NET platform imposes performance penalties on 16-bit integers. There is no IL representation for a 16-bit integer on the stack ”only 32-bit and 64-bit integers. This means that working with 16-bit integers puts code at a significant disadvantage , because every operation involves a conversion to catch overflow. For example, if a , b , c , and d are all 16-bit integer variables , the expression a = (b + c) * d results in two separate 16-bit conversion instructions (after the addition and the multiplication) to catch overflow. This overhead is nontrivial. When doing performance testing on early incarnations of the Visual Basic .NET compiler, Visual Basic performed at a disadvantage relative to other languages. Much of that disadvantage was directly attributable to the fact that the test was written using Integer . Once a search and replace on Integer with Long was done, the slowdowns vanished. The fact that Integer is the semantically default integer type made this issue a significant one.

The other main consideration was the fact that the .NET world is inherently multilanguage. In previous versions, Visual Basic and C++ inhabited totally separate worlds . To move data between them or make cross-language calls was difficult at best. By and large, the Visual Basic developer had the easier time of it than the C++ developer ”as long as the developer kept in mind that int was the same as Long , for the most part Declare statements would work. But because Visual Basic and C++ lived in such separate worlds, Visual Basic constantly lagged behind the curve. The Win32 world was so isolated and relatively incompatible that to take advantage of new system features often required utilizing "black magic" coding until the next version of Visual Basic was released.

Part of the promise of .NET is that all languages now have a simple, straightforward way of dealing with one another because they all work in the same world. Moving forward, new API sets will be rolled out as managed code, and when they do ”with no intervention by any guru or wizard ”those APIs will be immediately and fully usable by Visual Basic. By reducing the cross-language friction even more than has already been done by the .NET platform, we further encourage the connection between Visual Basic and the platform and the other languages on .NET.