# Demand More From VB

1/26/2004 8:37:24 PM

## Demand More From VB

I seem to hear that proponents of VB lament that the C# programmers are better paid, while there are no fundamental differences between the two languages, since they generate the same IL.

(The salary differences probably depend a lot more on the type of people who gravitate to the languages; C# programmers, many of which were former C++ programmers, are more likely to have better computer science education. A study, highlighting the different backgrounds, showed that the C# programmers found tended to find the .NET framework easier, while VB programmers, on average, tended to find it more difficult than VB6.)

VB even has a few convenient features that C# lacks. Reflection is much easier to use in VB, where any method called on a variable of type object uses reflection. Using OLE automation is much more convenient under VB. Try calling an method from the Word object model from C# which doesn't support default parameters. Check this simple example from MSDN for opening a file in Word contrasting VB with C#.

' Visual Basic
ThisApplication.Documents.Open("C:\Test\MyNewDocument.doc")
// C#
object missingValue = Type.Missing;
object fileName = "C:\\Test\\MyNewDocument.doc";
ThisApplication.Documents.Open(ref fileName, ref missingValue,  ref missingValue,
ref missingValue, ref missingValue,  ref missingValue, ref missingValue,
ref missingValue,  ref missingValue, ref missingValue, ref missingValue,
ref missingValue, ref missingValue, ref missingValue,  ref missingValue,
ref missingValue);


C#, however, does offer better access to the platform with constructs such as unsafe programming and unsigned data types and doesn't carry with it any extra runtime.

Unfortunately, I am always struck by some new limitations on VB, how it does not convey all of the power of the CLR, or doesn't always compile to the most efficient representation of code in IL as in C#, many times opting for unnecessary reflection or boxing. Reflection is at least 400 times slower than the optimal representation. There seems to be a direct correspondence between the CLR and C#, that doesn't exist in VB. You would think equivalent code from VB and C# generate the same IL, but this is often not true. It seems to me that VB team was more concern about converting legacy code and that the first version feels like a port.

Take this point on object to structure conversion. Why on earth does VB call Activator.CreateInstance to create a structure, when IL contains instructions for directly initing a structure at a huge performance gain? VB also has other random limitations that don't exist in other .NET languages like not being able to derived a class on an interface, if a base class already derives from the same interface.

Most of the VB runtime functions and keywords perform poorly against the framework, and it's not because of the existence of another layer. The conversions functions like CInt() perform boxing prior to converting. The poor performing IO Functions should be ignored in favor of framework equivalents. A notable difference between C# and VB is in the use of For Each in VB, which always construct a IEnumerator object at the beginning of the loop. In C#, it's possible to have an allocation-free foreach loop, because the compiler calls the enumerator methods directly.

VB programmers should demand a better performing language from the Microsoft with more support for available CLR features. Fortunately, things are looking better in Whidbey. The next version of VB is adding the following C# equivalents to the language for parity:
1) Continue, Using
3) Unsigned Types

Also, reflection, which VB makes much use of, is being complete rewritten for performance. A quick look at the SSCLI source code indicated that the original version of reflection was written for generality and not optimized at all. The improved performance means tools will run faster and that reflection will become a more attractive alternative style of invoking methods.