I guess I just don't get it...
I know I’m setting myself up for a beating… but I just don’t get it. How is it that people still have such a hard time accepting the Microsoft.VisualBasic assembly as being part of the .NET Framework? Why is it that they always state that it’s there only for the sake of compatibility or legacy? There are people who use VB.NET that when they create a new project, immediately remove this assembly from the imported references. People who use C# (by choice or by necessity due to job requirements) are always asking “In VB I used __, how do I do __ in using C#?” and they either don’t realize that they could just add the assembly as a reference and utilize said functionality or they refuse to for one reason or another to even consider it.
Like I said, I just don’t get it. It’s every bit a part of the Microsoft .NET Framework (the product that is named by Microsoft, that targets various versions of Windows (98SE, ME, 2000, XP, 2003) and has, as of this date, two major releases. In the two releases, the Microsoft.VisualBasic assembly has made little to no noticeable changes. It’s still there. Not going to be leaving us and available everywhere the Microsoft .NET Framework is installed.
So why is it that people avoid it? Here are some of the answers that I’ve heard.
- It’s there purely for the sake of compatibility with legacy VB (VB6) and code being migrated to .NET.
- The methods in there are slow.
- It’s not objected oriented in design.
- Not the “.NET Way”. If you have to use multiple languages, why learn two ways to do a task?
- It’s not part of the core language?
- It’s written in VB.
- If I add to many references to my application, it will slow it down.
- Not cross platform.
Let me try to answer each one of these in some detail.
It’s there purely for compatibility with legacy VB
This is a hard one to contradict. First, there are a lot of similarities with previous versions of VB. Of course, to me, this would be obvious since we are still talking about VB. I would expect a certain level of functionality from previous versions to exist in a newer version of the product. What is even more interesting is we have two sides to this argument. We have one extreme side that refers to VB.NET as Visual.Fred who say that VB looks nothing like VB6. Then there’s the other extreme stance that has the half-baked notion that VB should drop all of this stuff and do everything manually using the methods from the System namespace (assuming there is even a counterpart). Having multiple ways to do tasks is not a bad thing. Also, just because the methods existed in previous versions of VB doesn’t automatically make them outdated or reduce their usefulness.
The methods in there are slow
This one is partially correct and really depends on how you look at it. How slow is slow? What defines this? What is the breaking point for something to be considered too slow to be useful? What I mean is that, without getting into a lot of detail, slow is relative. Just because one method is slower than another doesn’t really make it slow per say. In many cases, the two similar methods are approaching the problem from two different views. In other cases, there’s overhead introduced to make the methods more robust and more of a generic workhorse that works in most situations. In the end, the performance you incur isn’t necessarily even noticeable. It depends on the target audience (single user, a handful of users, an enterprise or even a wider audience) and the targeted platform (Windows Forms / ASP.NET). Also, what other functionality is being used can effect overall performance. Have a few string concatenations inside a method that is doing a lot of Web Services calls… the Web Services calls will probably be a lot more of a performance hit and what the GC is going to do with a few released strings. However, for the sake of argument, we’ll assume this from a pure CPU performance standpoint.
There are some methods, some that are soooooo slow that I think Microsoft should seriously do some performance tests to improve them. Even if they aren’t used all the time, having them as slow as they are is ridiculous. Methods in this category are all of the file i/o methods. These things just plain suck when discussing performance. However, if you need to read/write fixed length data (assuming your willing to turn Option Strict off), then these methods could be your best friend.
There are other methods that are only marginally slower or equal in speed. They have a slight overhead since they are actually doing some additional checking that is potentially protecting you from various development/platform pitfalls. Of course, you could do all of these checks yourself in a manner that would be streamlined for the specific task at hand; thus improving the performance. However, since these methods are somewhat generic, they take several of the pitfalls into account and prepackage them into a workhorse, generically reusable package.
Finally, there are some things that fall way outside of this “slow” category or just plain don’t count in relationship to performance since there is no counterpart in the System namespace. The Split method is “slow” when comparing it to System.String.Split for single character delimiters. However, System.String.Split doesn’t support multiple character delimiters and, instead, you have to use System.Text.RegularExpression.RegEx.Split… which is significantly slower than the VB Split method.
Now everything that I’ve presented in this section has strictly been regarding performance in CPU terms. What about performance in code readability and supportability? What about developing code that is more robust and bug free? How much time should be dedicated to finding an alternative to something that you immediately have an answer for?
It’s not objected oriented in design
This one I really don’t get. Each method is structured in a namespace hierarchy, grouped with other methods of like functionality and defined as Shared (static in C# speak). What about this assembly is any less object oriented than say System.Text.RegularExpressions.RegEx or any other functionality in the .NET Framework? Maybe I don’t understand object oriented enough to see how this statement applies to the Microsoft.VisualBasic assembly.
Not the “.NET Way”. If you have to use multiple languages, why learn two ways to do a task?
This one is probably the one that gets to me the most. What exactly is the “.NET Way”? Where is this defined? What excludes any part of the .NET Framework as not being or another as being the “.NET Way”?
To me, the “.NET Way” is to leverage the .NET Framework utilizing any language of our choice. To leverage the .NET Framework, we can use the functionality contained within the System namespace or ANY assembly that houses reusable code to get our jobs done. If I were to create a reusable framework to play and record audio files, share this with other developers and they end up using it… are they not using the “.NET Way”? What makes the Microsoft.VisualBasic assembly any different? I guess I think of the “.NET Way”, as a base, meaning leveraging anything the platform has to offer. If this means writing an assembly in C# because it’s easier for a specific than writing it in VB.NET, I do so. If this means I have to use Managed C++ to wrap a LIB file so I can use it from VB.NET, I do so. I can also leverage any assembly that ships with the .NET Framework; which includes Microsoft.VisualBasic.
The beauty of the Microsoft.VisualBasic assembly is the fact that it is housed within a reusable assembly that, technically, any language targeting the .NET Framework can leverage. So there’s not a whole lot of reason to say that you couldn’t use DateAdd/DateDiff or VB’s Split from C++, C#, J# or any of the other 20+ languages targeting the .NET Framework.
It’s not part of the core language
Another one that I really don’t understand. How Microsoft implemented the specific of VB is not really an issue in regards to the “language”. Just as the .NET Framework is made up of several pieces (CLI, CLR, ADO.NET, ASP.NET, Windows Forms and the Managed C++, C#, VB.NET and J# compilers), VB.NET is made of of several pieces as well. The Microsoft.VisualBasic assembly is just one component that makes up the VB.NET language. This, to my understanding, will be even more true with the release of the next version (Visual Basic 2005).
It’s written in VB
Now this isn’t an answer that I’ve gotten per say. More of one that I have felt while discussing this with various people. When you hear that someone uses Reflector to reverse engineer a method contained within the Microsoft.VisualBasic assembly and port the code to C#… I think there’s credence to this being one of the reasons. This seems like an awful lot of work to reuse the functionality that already exists within the .NET Framework and exists on EVERY machine that the .NET Framework is installed upon.
If I add to many references to my application, it will slow it down
This can be true. However, I think it’s less true for the assemblies that are contained within the .NET Framework since they are NGen’d upon installation. This means that the JIT’er doesn’t have to JIT any portion of the assembly in order to add a reference, the code is already in native form. I don’t see this as being any different than adding a reference to a Win32 style DLL, which has very little overhead. If I’m wrong in this assumption, please correct me… I’m willing to listen. All I can say is that adding this one reference has yet to give me any indication of causing a performance problem.
Not cross platform.
This one is a tough one to me. Although the statement is partially correct, it’s not a complete answer. Many of the methods in Microsoft.VisualBasic are supported on the Microsoft .NET Compact Framework, while some are not. Of course, this is true for a far greater amount of functionality contained within System as well. I’ve heard Rotor. Well, Rotor, in my opinion doesn’t really count for several reasons such as it’s purely for academic use and doesn’t contain much of what makes up the .NET Framework (see above). Then there’s Mono. Well, if you want to measure today… this statement is still only partially true. Tomorrow (Mono 2.0), it should be completely false if Miguel and his team of developers stay on track. In the end, cross platform is still, in many ways, a pipe dream. It’s one of those far reaching niceties that we would really enjoy having, but not one that would kill your project. In the day to day real world working environment, you most like are leverage the targeted platform for everything you can milk out of it. Most people aren’t writing their applications to target multiple platforms… just as people aren’t writing their applications just so they can rewrite it in another language. Also, if you are really concerned with cross platform development, right now, meaning today, there are products that do this a whole lot better than even Mono. This is changing rapidly and I really do hope that it will be a true reality in the near future, but in the same breadth, I’m not really all that concerned about it.
A similar subject has come up in my Mono discussions. The question is “How complete is Mono?”. Well, that depends on how you gauge complete. Some people would measure it by how well it meets the CLI/C# specs. Others would measure it by how much of the Microsoft .NET Framework compatibility is done. There are even others that would reduce this to a specific set of Microsoft technologies (ASP.NET/ADO.NET). In the end, how complete Mono is relates very specifically to whether or not what is implemented meets your own needs. Your the only one that can really make that judgment.
VB is a lot like this. Without the functionality in the Microsoft.VisualBasic assembly, how complete is VB? To me, it’s incomplete. Sure, your still able to write applications that target Windows… but I could say the same thing of QuickBASIC 4.5 or Visual Basic 1.0. There are a group of people that are still stuck on the issue that when VB 7.0 Beta 1 was released, a lot of this so called legacy functionality was somewhat removed from the language. There were a group of people that said that it was not acceptable. Some of what they said was, to me, kind of stupid. However, they were right from the standpoint that in order for VB.NET to be the next VB, there’s some things that should just be there.
VB.NET 2002/2003 are still incomplete in my opinion and VB 2005 appears to be correcting a lot of these shortcoming. Will I be happy? No… I’m still going to want more and, trust me, there’s still a lot more that can be done; however, to me, VB 2005 is shaping up to what I would consider a good version 1.0 version of the next BASIC.
Also, someone asked why isn’t this functionality in the System namespace if it is, as I suggest, so usable? This is a pretty good question and one that I can’t really answer definitively. However, I can guess that it’s because the rest of the .NET Framework team didn’t find it useful when targeting other languages (or many other possible reasons) and the VB team thought otherwise. For functionality that the other teams couldn’t agree on being there (for example, something as simple as Beep), the VB team has a place to put this. This doesn’t stop other languages from utilizing it and in the end, it’s just a namespace. That’s the beauty of .NET… namespaces allow you to have a lot of functionality without the fear of naming collisions. This is why you can have Microsoft.VisualBasic.Strings.Split and System.String.Split and System.Text.RegularExpressions.RegEx.Split available in a single application. It’s good to have choices. Just don’t let those choices be decided based on language bias and inaccurate information. Test it for yourself. Give it a go. If it works for you, great. If it doesn’t, don’t deter others from having the same opportunity. If your using VB, think of it as part of the language. If your using another language, think of it as a reusable (always available) library of things you might not find anywhere else (Asc, financial functions, faster Split when using multiple-character delimiters).
So did I cover them all? I’m I mistaken on any of the response to any of them? Let me know what you think… let the beating begin…