There are a few "givens" that one must consider and accept when dealing with this obviously sensitive issue.
Second is that VB.Netters, as a Gestalt, have a large contingent of proponents who defend VB.NET not with logic, but with a religious fervor that occasionally borders on insanity, taking any jab at VB.NET by anybody at all as some kind of personal attack. That's obvious if we simply read all the blogs about Richard Grimes' parting piece in DDJ. Even Carl Franklin, whom I'd otherwise consider to be a pretty classy guy, seems to have jumped into the sewer on this one.
There are many programmers who write terrific code with VB.NET. Unfortunately, there are far more who do not, and according to Nigel Shaw, who has a recent "culture" piece at CodeProject. one of the primary contributing factors is the fact that the language was created out of a culture that permits low-quality, error-prone code to get compiled.
My personal view about this is mainly born out of the culture aspect. I believe that I understand the history and culture that were responsible for the so-called "VB" mentality, because I was a part of it for a number of years. I didn't get as much exposure to the so-called "C# culture" until after I had made the conscious decision to switch to C# as my primary programming language when the .NET Framework came out. This decision was not made easily; I had become very "comfortable" with Classic VB and VBScript. Inertia (resistance to change) is a very objective thing - we all feel it.
However my decision was made based on what I considered at the time to be overwhelming facts, figures and arithmetic in favor of taking the much "harder road", if you will. It was not until I worked for a company that enforced what I now consider to be a particularly mindless "VB.NET Only" development strategy that the full effect of what can go wrong with VB.Net came to the fore. Needless to say, I no longer work there, although I am still exposed to some of the absolutely crappy code that VB.NET programmers have left for me to work with at my current place of employment. Suffice to say, our developer group all feel a sigh of relief now that we have almost totally converted all this VB.NET code that we inherited to C#.
And the final "given" is that neither C# nor VB.NET is going away anytime soon. So, we all might as well get comfortable with each other and learn to try and play from the same score. For VB.NET programmers, this really means understanding that the language you are using has built-in crutches that were primarily put there to hopefully ease your transition from classic Visual Basic and which have very little to do with the .NET Framework proper. The Framework and the CLR already has everything it needs and if VB.NET did not exist, nothing in it would change. Please understand that. For C# programmers (and VB.NET programmers too), especially those that did not come from C++ , JAVA or other more object-oriented programming environments, it means being willing to throw away the spaghetti-code techniques you may be used to, and learning to deal with true objects using encapsulation, polymorphism, interfaces, virtual and abstract classes, and much more.
Another important thing to consider: You can apply the CLSCompliant attribute on an assembly (or a program element) and have the compiler check if your code is CLS (Common Language System) compliant. This means it works properly when consumed by other .NET languages. For example, you can place the following attribute on your .NET AssemblyInfo.cs files:
Some of the things the compiler checks:
Class and member names cannot differ only by case. For example, you can't have one property named Counter and another named counter. This is important for cross-language compatibility since VB .NET isn't case sensitive.
Overloaded class methods cannot differ only by out or ref parameter designations.
Publicly exposed members cannot start with an underscore ( _ ).
Operators can't be overloaded
Unsigned types can't be part of the public interface of a class
Unfortunately, although you can apply the CLSCompliant attribute in VB .NET, the VB .NET compiler doesn't check for CLS compliance. "Ah," you say. "Now I understand why ONLY C# was submitted to and accepted for language certification by ECMA." One point I should make here, based on some recent comments, is the fact that you can create CLS- Compliant classes with VB.NET. And you should consider doing so. As I mentioned above, everything you need is already in the BCL and you do not need to use the namespaces with "VisualBasic" in their names. VB.NET is not a "bad" language; it just allows you to get away with perpetuating bad programming habits. That's the culture part.
For VB.NET programmers, If you turn on Option Strict and Option Explicit, and avoid using the crutch class methods like CType instead of DirectCast, and use the Framework Convert class instead of "CInt", you are well on your way to writing CLS - compliant code. And for Heavens sake, learn to use the Exception class and its derivatives -- and learn it well. Oh, you won't like it, because all this puts the VB.NET compiler pretty much on the same level as writing in C#. You'll be forced to really think. You will often hear that both VB.Net and C# generate the same MSIL code. THEY DO NOT. However, if you follow the above suggestions, it will at least be similar in its performance characteristics. You can write code in VB.Net that does not depend on namespaces with "VisualBasic" in their name. Try it -- you'll be surprised at the new power the .NET Framework offers to you. You still won't be able to use pointers and other unsafe code constructs, but that's not the main issue.
And -- if you take my advice and still want to be a VB.NET programmer, you'll become a better one. Who knows -- you may very well decide to abnegate your relationship with that beloved VB as I did, and decide you'll actually be better off with C# after all.
The debate really begins to take a back seat when you begin writing managed code with C++ -- which has become a good portion of what I am doing now. Managed C++ and the ability to generate mixed mode assemblies -- is absolutely awesome!
As a final note, I didn't initially take up C# because I had a pressing need for pointer arithmetic or operator overloading, although I occasionally need them now. I do know why, once I learned C#, that I stopped writing VB.Net. I just happen to prefer C#’s syntax: less redundancy, fewer unnecessary keywords and language constructs. I don’t want to have to write "Dim foo As Bar" when I can simply write "Bar foo".
VB.Net doesn't look the way it does because some language designer thought carefully about
what would make a good syntax for a language, but because it was advantageous for Microsoft to be able to persuade VB6 programmers that VB.Net was just the latest upgrade to their favorite language in order to get them to adopt .NET.
I wish VB.Net would go away because there isn’t any real, compelling technical reason for it to exist. It exists mainly because Microsoft needed to persuade the VB6 developer community to move away from a language it was going to abandon, and it has inherited many of the crutches and ugliness of VB6 without maintaining any real continuity with that language. C# is not perfect either, but at least it’s not a half-assed attempt to fulfill an essentially deceitful marketing campaign.