C# Versus VB

Here's an interesting article by Nigel Shaw about the fiercely contested debate regarding C# vs. VB.Net.

 

http://www.codeproject.com/dotnet/CSharpVersusVB.asp

 

Let me say up front that I in no way agree with all of the comments or "opinions" made in the article, but I do think it's an interesting point of view. More than anything though I think he makes a great point regarding the fact that C# and VB are functionally equivalent!!!

 

Excerpt from Article:

We've seen that the cultures of VB and C# are very different. And we've seen that this is no fault of the programmers who use them. Rather this is a product of the combination of factors that collectively could be called their upbringing—business environment, target market, integrity and background of the original language developers, and a myriad other factors.

 

Excerpt from Article:

The brilliant insight Microsoft had was not to support multiple languages—if this was the case then surely it would not have bothered with J#, which is syntactically so close to C# that support for language’s sake alone would be ridiculous. The insight Microsoft had was to support multiple cultures.

 

One thing I found intersting in his article was his "In concrete terms" list regarding various statistics on C# vs VB programmers. Keeping in mind the numbers he uses are "opinions" and not actual statistics. But with that said, the one item I think is most important is:

 

A good programmer accomplishes two to ten times what an average programmer accomplishes, and causes 90% less bugs and headaches.

 

Regardless of language preference, I think the definition of a good programmer should be based on the quality of the code, performance, scalability, and long-term effectiveness of the code, not whether or not you chose VB or C#.

 

Examples of key differences between C# and VB are listed below. These are simply examples and not an exhaustive list:

1. VB by default allows support for late binding. Although it can be turned off with Option strict, the culture is such that it’s usually left on. This leads to numerous difficulty to catch errors. C# binding is always early.
2. VB still supports the old On error goto construct. This leads to sloppy or non-existent error handling. C# supports only the superior try…catch error handling.
3. VB supports optional parameters. Although VB developers often list this as an advantage, it is a disadvantage because the use of optional parameters weakens the contract between the caller and the method, allowing the developer to slacken his analysis and get away with it until bugs creep in. [Note: C# param array construct is not the same as optional params]
4. VB supports the legacy VB functions, with reference to Microsoft.VisualBasic.dll. Many of these functions are slow and they should all be avoided in favor of the .NET Framework. However many VB programmers still use them. In new VB projects, this dangerous namespace is included by default.
5. VB allows implementation of interfaces with methods of different names, making it confusing and difficult to find the implementation. C# does not.
6. VB supports background compilation. While this speeds the development cycle for small projects, it slows down the IDE in large projects, contributing at least in part to the culture tending to gravitate toward small projects.
7. C# namespaces are managed in way that makes programmers aware of namespaces and their importance. VB namespaces are managed in a way that hides them from the programmers by default. Careful attention to namespace management is a fundamental tenet of strong application design and its importance cannot be overestimated.

The reason I'm posting a link to this article in the first place is because too many times when I'm researching a solution or looking at an article online I see someone post a code-snippet in VB or C# and there almost always is another post asking for the code to be converted to the other language. That of course always leads to a steamed argument about which language is better and why.

Taking the time to really understand the languages and the framework would solve most of these arguments and it would become very clear, in my opinion, that it's a matter of preference.

I come from a classic ASP and VB6 background, so naturally when .Net was evolving I made the quick transition to ASP.Net and VB.Net. I did very little to no C# programming for the first year or so. Not because I thought it was inferior, but because it was easier for me to continue down the VB.Net path and frankly most of the clients I was working with at the time had standardized on VB.Net, which made the decision even more obvious.

With that said, however, for the past few years I've became very involved with C# projects and I consider myself extremely fluent in both VB and C#.

I'm always learning new techniques each day, in both languages, so it makes it extremely rewarding to be able to be open-minded from project to project and make a seamless transition from one to the other at any given time.

My personal opinion is that if the client has standardized on a language, we as developers should honor that unless there is an obvious reason not to, and in certain circumstances I'm sure there are good reasons to make a recommendation.

I think the best thing is to be flexible and know as much as you can about both languages, as there are most certainly going to be times when you have to work on a project that isn't your language of choice.