Home > Development, Microsoft > Why Microsoft.VisualBasic should be buried

Why Microsoft.VisualBasic should be buried

A friend of mine, who I hope won’t object to me recounting this anecdote, was recently posed the following interview question:

What would you change about the .NET framework?

To me, the answer was simple: I would deprecate the Microsoft.VisualBasic namespace with immediate effect, and phase it out entirely by the time version 5 of the framework was rolled out. It is a relic of a language that ceased to be ‘current’ 10 years ago, yet is still being actively used; even this week I have seen code, recently written to run under .net 3.5, actively using methods from it.

To understand the reason for it existing, it is worthwhile looking back to when .net was introduced. Microsoft was targetting two separate groups of developers: those coding in C or C++, for whom it developed C#, and those moving forward from Visual Basic 6. For this latter group, they included a number of VB6 commands, using them as wrappers around the .net equivalents; these were placed within the Microsoft.VisualBasic namespace, with it being automatically included as a referenced namespace in all new VB.net projects. As Microsoft go on to say in their page about Visual Basic .NET internals,

An important goal for Visual Basic .NET was to retain as much backward compatibility as possible, while providing more power and flexibility for the developer. This was accomplished by providing “helper” methods such as Rnd (which is a static method on an imported class) and intrinsic language features, such as CInt, to provide functionality identical to that of Visual Basic 6.

Unfortunately, not all VB6 developers embraced the object models available, and as a result far too many developers are still using the constructs such as CInt() as shortcuts to the .net equivalents. Those developers presumably assume that CInt(number) is equivalent to int32.parse(number) both in functionality. Nothing can be further from the truth; from the same page:

While there are a few specific methods that don’t provide the same performance characteristics as Visual Basic 6, you can fully expect that a Visual Basic .NET application will significantly outperform its Visual Basic 6 counterpart.

Our simple CInt() function performs a wide variety of options, covering parsing, boundary checking and rounding. Using it leads to inefficient code and, more importantly in my mind, developers who are unskilled in the wider concepts of OO within the framework.

Microsoft.VisualBasic is a relic, and deserves to be buried.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: