Language Cleanup

As should be clear by now, moving to the CLR entailed some radical changes to the Visual Basic language. On top of the language changes, there were a number of library changes (such as the move from Visual Basic forms to .NET Windows Forms) that also significantly changed the way that code is written in Visual Basic .NET. Because of the magnitude of the changes necessitated by the CLR, 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 CLR 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 the CLR. Each change was in response to specific feedback that the team had gathered over the years , and each was considered 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 . Both through feedback and experience, the pieces of the language that were dropped were ones that were rarely used by developers (in some cases, largely forgotten by users) and did not provide significant programmer benefit. A few of the other changes corrected quirks , like changing Wend to the more regular (and grammatical ) End While . Most of these corrections are automatically handled by the migration tool and by the IDE editor (i.e., when you hit 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 CLR 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 we were doing performance testing on early versions of the Visual Basic .NET compiler, Visual Basic performed at a disadvantage in relation 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 performance problems vanished. The fact that Integer is the semantically default integral type made this issue a significant one.

The other main consideration was the fact that the CLR world is inherently multilingual. In previous versions, Visual Basic and C++ inhabited almost 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 they 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 separate and relatively incompatible that to take advantage of new system features often required using black magic coding until the next version of Visual Basic was released.

Part of the promise of the Common Language Runtime, though, is that all languages now have a simple, straightforward way of dealing with each other because they're all working in the same world. As we move 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 further than has already been done by the CLR, we further encourage the connection between Visual Basic and the platform and the other languages on the CLR.