VB.NET vs C# Debacle Rages On
There are a few "givens" that one must consider and accept when dealing with this obviously sensitive issue.
First is that you aren't going to make case-sensitivity go away. It's built into too many languages, operating systems and standards. XML, UNIX, C++, and of course C# just to name a few. If you write VB.NET code you may wish to consider that fact, especially if you anticipate that programmers using other languages are going to be using the classes you write. Personally, I find case sensitivity to be a good thing. It forces me to think a bit more and serves as an additional check on writing quality CLS-Compliant code. Think of it as the "literary approach": If you are the kind of individual who -- through either laziness or lack of education -- can't spell, use proper English grammar, capitalize words correctly, and you do things in your language such as use the word "loose" when you really mean "lose", then probably VB.NET would be a better fit for you. And, don't use Javascript. It's case - sensitive too. Point is, you can rail against case-sensitivity until your face turns blue; it's just not going away; yet this seems to be one of the major gripes of "VB.Netters" about not wanting to learn / use C#.
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:
[assembly: CLSCompliant(true)]
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.
First is that you aren't going to make case-sensitivity go away. It's built into too many languages, operating systems and standards. XML, UNIX, C++, and of course C# just to name a few. If you write VB.NET code you may wish to consider that fact, especially if you anticipate that programmers using other languages are going to be using the classes you write. Personally, I find case sensitivity to be a good thing. It forces me to think a bit more and serves as an additional check on writing quality CLS-Compliant code. Think of it as the "literary approach": If you are the kind of individual who -- through either laziness or lack of education -- can't spell, use proper English grammar, capitalize words correctly, and you do things in your language such as use the word "loose" when you really mean "lose", then probably VB.NET would be a better fit for you. And, don't use Javascript. It's case - sensitive too. Point is, you can rail against case-sensitivity until your face turns blue; it's just not going away; yet this seems to be one of the major gripes of "VB.Netters" about not wanting to learn / use C#.
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:
[assembly: CLSCompliant(true)]
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.
ReplyDeleteFor VB.NET programmers, If you **snip** 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 CLR - compliant code.
Can you explain why using CType and CInt results in non-CLR compliance?
I can see how you might not like them - but thats different to CLR compliance...
When converting from an object to a value type, or unboxing, the DirectCast operator has better performance than the CType operator.
ReplyDeleteThe Visual Basic .NET compiler generates just four lines of IL code for DirectCast.
However, using CType causes the Visual Basic .NET compiler to generate a call to a conversion method that is well over one hundred lines of IL code long.
This method in turn calls other methods. In performance critical code, the difference can be substantial.
DirectCast provides us with faster MSIL code and is used only within reference types. DirectCast produces native MSIL code like C# will produce, compared to CType which has to go through VB.NET runtime class library. Obviously if something you write "Has to" go through and creates a
dependency on the VB.NET runtime library, the likelihood that it could ever pass the "CLS Compliant" attribute test becomes that much more remote.
The Microsoft.VisualBasic.dll assembly is not marked with the CLSCompliant(true) attribute.
ReplyDeleteTherefore, you cannot use the Microsoft.VisualBasic.dll assembly in applications that require
assemblies to be referred or to be marked with the CLSCompliant(true) attribute.
(Courtesy of Lutz Roeder's Reflector):
// Assembly Microsoft.VisualBasic, Version 7.0.5000.0
[assembly: AssemblyVersion("7.0.5000.0")]
[assembly: NeutralResourcesLanguage("en-US")]
[assembly: AssemblyCopyright("Copyright (C) Microsoft Corp. 2000-2002")]
[assembly: AssemblyCompany("Microsoft Corporation")]
[assembly: AllowPartiallyTrustedCallers]
[assembly: AssemblyKeyFile(@"f:\VS70Builds\6001\vs\src\common\security\FinalPublicKey.snk")]
[assembly: ComCompatibleVersion(7, 0, 3300, 0)]
[assembly: AssemblyTitle("Microsoft Visual Basic .NET Runtime")]
[assembly: AssemblyDelaySign(true)]
[assembly: AssemblyDescription("Microsoft Visual Basic .NET Runtime")]
[assembly: SatelliteContractVersion("7.0.5000.0")]
[assembly: TypeLibVersion(7, 1)]
Hi Peter,
ReplyDeleteYour comment above about CLS complliance is misleading. The fact that the MS.VB dll itself isn't marked as CLS compliant doesn't prevent anyone from writing their own libraries or frameworks in VB that are CLS compliant, which is most likely what people are after.
Steven
That is absolutely correct. Nothing stops one from using VB.NET to write 100% CLS Compliant class libraries. In fact, that was a major thrust of this piece - that the Framework already has everything we need, whether we address it with VB.NET , C# or any of 20 other languages.
ReplyDeleteYour post doesn't seem especially well thought out.
ReplyDeleteFirst of all, what does case-sensitivity have to do with one's ability to spell or use English? The primary value of case sensitivity is that I don't have to waste time correcting typos because the VB.NET compiler automatically changes the case to match that of the declaration.
Second, what does "CLR compliant" mean? Presumably, you meant "CLS compliant". Strange that you would get this wrong since this is the thrust of your point. Perhaps you are "the kind of individual who -- through either laziness or lack of education -- can't spell, use proper English grammar, capitalize words correctly, and you do things in your language such as use the word 'loose' when you really mean 'lose'."
Due to my inherent laziness and lack of education, I must rely on kind souls like you to help me correct my posts.
ReplyDeleteHowever, I shall not loose focus on the bigger meaning in your excellent comment.
See
ReplyDeletems-help://MS.VSCC.2003/ MS.MSDNQTR.2005APR.1033/ vblr7/html/vakeyDirectCast.htm -
This makes it very difficult for those reading Microsoft literature to ever use DirectCast.
"Dim Q As Object = 2.37 ' Requires Option Strict to be Off.
Dim I As Integer = CType(Q, Integer) ' Succeeds.
Dim J As Integer = DirectCast(Q, Integer) ' Fails.
In the preceding example, the run-time type of Q is Double. CType succeeds because Double can be converted to Integer, but DirectCast fails because the run-time type of Q is not already Integer. "
If Q was already an Integer, why ever use DirectCast? Also, elsewhere, Microsoft lauds the use of CType, so how does one get VBers to use DirectCast in the face of apparent more functionality even though more lines of compiled code are used?
So? What's wrong with:
ReplyDeleteDim K As Integer = Convert.ToInt32(Q)
??
My comments were never intended to be taken that you should "ALWAYS" use DirectCast; the general tone was about writing type-safe code and CLS-Compliant code.
Well, Sir,
ReplyDeleteI believe you have just hit the nail "right between the eyes".
I believe the major concern in business between VB.Net and C# is the "RAD" issue.
ReplyDeleteMost larger companies want Rapid Application deployment, weather it is sloppy or not, becuase the manager has no idea how to distinguish between it. All he knows if that VB was written faster, and delivered to the end-user on time.
I'd like to think of myself as the reare category that you mentioned above. I have been using "Basic" for the past 18 years and have been using C# for about 1 year. I prefer VB for smaller tasks, there is no need for me to spend hours on somthing, that isn't mission critical. Altho, I'll admit that i do like C# better for application where i don't want to find out 6 months down the road, that i made a poor choice on implementation, and have to re-write half of the code.
Noone is a perfect coder, and everyone has thier own "way" of getting the same task done. But realistically, if the poor VB.Net coders had taken better care to be worry about performance and run-time stability, VB.Net would not have such a bad name.
VB.Net 2005 just got released in the past few days, It now allows Non-CLSCompliant data types (ie.. UInt), which C# has always allowed. So now that the biggest limitation to VB was removed, you should expect more people to be using it for it's faster development time. I will be completely honest though.. If coding in VB takes you less time than coding in C#, it's probably becuase your cutting corners.
Sorry, i just thought of good example to post, after i re-read my previous one. This applies to anything .NET
ReplyDeleteHashtable, ArrayLists, etc.. yea, sure they are all nice and fancy, and easy to use. But everything has it's place & time. I see a lot of people using these where they could have just used a simple String-Array.. Dim xx as String() or String[] xx.
Most people don't understand, that everytime you "arraylist.Add(blah)".. internally .Net is executing a tun of code to make a new array with the same size+1, then copying the data over to it.
This is the sort of thing that hurts performance. It's not nessicarily the tools your given, it's how you use them. I come from a world where the fancy features never existed, and most of the wrappers that they call "the .Net Framework" was coded manually. So i probably have a totally different perspective on things.
You know.. I ended up here, becuase I wrote some code years ago that used DirectCast. And I was trying to convert the code to C#, but the class didn't not seem to exist in the framework.
ReplyDeleteSeems like it is not a class, it is a Keyword existant only in VB. You might want to remove that from your Pro-C# blog =x.
But, Quoted from the MSDN-2005..
"DirectCast does not use the Visual Basic run-time helper routines for conversion, so it can provide somewhat better performance than CType when converting to and from data type Object."
Perhaps we would all be better served about DirectCast if we read the item in the blog from the developer at MS who was directly involved in creating it?
ReplyDeletehttp://www.panopticoncentral.net/archive/2003/07/10/149.aspx