Update: The Agile Developer pointed out that refactoring support and some other features are in fact supported for VB in VS 2005. This is not meant to be controversial, as I despise the practice of being offensive just to try to create traffic. This article is a combination of my own biases and a possible explanation for "Why do people bash VB?" Don't kill the messenger.
The google searches are a little slow today and The Agile Developer made a post and used VB.NET in his example so now's as good a time as any to resurrect my extreme dislike of VB.NET. VB.NET is not "equal" to C#, regardless of what marketing material you may have read that tells you it is. I could drone on all day about how much worse my carpal tunnel would be if I had to keep typing
public overridable shadows Sub ThisIsMyMethodName() as MyReturnType
or about how much I dislike setting
option Strict on;option Explicit on;
in order to enforce strong typing in an already strongly typed language. Without these options there would be nothing wrong casting an instance of System.Web.Form to say, an instance of System.Integer. Nor will I drone on all afternoon about how annoying these options make any form of OO programming, since turning them on means if I have a type Child that extends type Parent and a method that accepts an argument of type Parent I have to cast descending classes down to the base type (I guess strict means "So strict we don't trust you with Object Oriented programming") before the compiler will accept it. If I enjoyed using obscure pre-compiler directives to make things work right I'd go back to creating C++ apps that run on multiple unix flavors: no shortage of #pragma directives there to keep me happy.
Also missing from my lecture this afternoon will be how crippling not being able to override operators is, since many framework class methods such as ArrayList.Contains make use of "==" and not "MyClass.Equals" for its testing. If anyone can remind me how to initialize an Array with a given size in VB I would congratulate you for keeping the roughly 39 uses of the paren "()" straight. Finally, if I think it is ludicrious to have to specify which one of my methods implements an Interface method (public sub MyFunction() as string implements ICrap.MyFunction) then that's just one man's opinion, of course. Since the man in question is obviously an elitist anyway we should not concern outselves. If you want to program in an IDE that enforces Word-like AutoCorrect syntax fixers on your code, that's your problem. Many times on user groups I have seen a question posted regarding some data binding or Reflection issue related to case sensitivity, ie MyMethod is not the same as mymethod to the CLR. "How can this matter in a language that's not case sensitive?" If the previous statement does indeed seem like a very good question to you, please stop reading now.
For various logical reasons, a lot of people do not like VB.Net. Some of these are stylistic choices and some are just plain pains in the ass where certain programming tasks are concerned. Before I go on, let me make a couple of disclaimers:
The VB community has gotten a bad reputation over time. There, I said it. For many years there were C/C++, Java, Smalltalk developers who just plain did not consider VB a "real" programming language. In the heyday of pre-.NET VB people developed the notion that "serious" programming was done in a different language, and VB was for creating poorly-designed front ends to a database. The fact that many VB developers did not have a traditional software engineering background and no Computer Science degree tells us a couple of things:
Let me propose this: When choosing a technology platform, you are also choosing the community of people who subscribe to that platform. This is not an original idea. C++ people tend to be different than Java people, who are slightly different than C# people, who are slightly different than VB.NET people. I claim the source of this often goes back to education : If you got a CS degree you probably took classes in C++, Assembler, had some Calculus, etc. If you got an "MIS" degree (or in some cases taught yourself) you probably had classes in SQL, COBOL, Accounting, and Visual Basic. In a world of elitist programmers, the former background is considered better than the latter. Don't shoot the messenger, I'm merely saying what everyone is thinking. If you want another warm body to write stored procedures, post an ad looking for someone with VB.NET; if you want someone with excellent software engineering skills, post a C++ ad.
Nowhere is this difference acknowledged better than at Microsoft itself. The Visual Studio team takes its direction to a great degree from ehancement requests by the user communities. While there are some differences in the way VS 2003 behaves based on programming language, the disparity gets wider in VS 2005. Take note of some popular new C# features
Versus VB
I'm vastly summarizing and obviously I am biased. My point is that things like this perpetuate the idea that VB.NET is inferior because a different type of person chooses VB vs. C# for their .Net development. We've all heard the rumour that the average C# guy makes a lot more than the average VB guy. Companies perpetuate this idea with hiring practices such as "We need 10 VB guys and 1 C# Architect on this project"; one large local company I know of goes so far as to have a Frameworks/Architect team that develops tools in C#, which are then consumed by the project teams consisting of all VB.NET developers.
That is why I use C#: because I recognize the world-wide bias against the Visual Basic community.
I am proficient in VB.NET because I recognize that when it comes down to the code, there is very little real difference, with the only major item being stylistic preference. Comments and flames welcome as always.