Are VB.NET Developers Less Curious? Standardizing on VB.NET

Question

I'm asking this question as someone who works for a company with a 70% to 75% VB.NET developer community. I would say 80% of those developers do not know what an OOD pattern is. I'm wondering if this is the best thing for the health of my company's development efforts?

I'm looking at the tag counts on:
https://stackoverflow.com/tags
There are currently:
12175 .NET questions
18630 C# questions
2067 VB.NET questions

Checking Amazon, it seems like there are:
51 C# Wrox books
21 VB.NET Wrox books

On CodePlex there are:
979 Projects tagged C#
136 Projects tagged VB.NET

There is definitely less materials to learn from if you wanted to be a VB.NET developer. What would be a company's advantage to standardizing on VB.NET and hiring VB.NET developers? How does Microsoft answer this question?

Is the only two arguments:

1. We had these VB6 programmers and lets make them comfortable
2. XML Literals

If you work for a company that has completely standardized on VB.NET, can you post an answer explaining the pragmatic or technical reasons why they made that choice?

UPDATE:
More stats - O'Reilly Radar
State of the Computer Book Market 2008, part 4 -- The Languages

Answer 1

We're not standardized on VB.Net, and I often have to go back and forth between VB.Net adn C#. I'm unusual, in that I come from a C/C++ background, know C#, but actually prefer VB.Net (I severely dislike vb6/vbscript).

I say all this because it's important to remember the VB6 is NOT VB.Net. It's a whole new language and IMO does deserve to stand up next to C#. I really hated vb6, but I fell in love with VB.Net almost instantly. However, VB.Net did inherit some things from VB6, and not just a syntax style. I'm talking reputation, and that's not entirely deserved. But I'm also talking about the developer base that helped create that reputation. That seems to be part of what you're experiencing.

With that in mind, it looks like you're judging the language based primarily on popularity. Not that there's anything wrong with this. There's plenty to be said for the ability to more-easily find samples and community support. But let's at least call it what it is. And if that's your measure, there's certainly enough support out there for VB.Net to make it viable, and it's not hard to take advantage of the C# samples.

Also, we're still on .Net 2.0 where I work. For 2.0, I definitely prefer VB.Net. I like the syntax better and I like the way it does a few other things over C#. But I play around with Visual Studio 2008 at home. On 2008 I really prefer the C# lambda expression syntax.

Regarding your two arguments:

• For #1, that may not be such a good idea, though I suspect it's the primary reason for many shops.
• For #2, I've never used Xml literals. They looks nice, but just haven't been that practical.

---

Something I wanted to add: it seems like some of the recent C# features are actually intended to make C# work more like VB. Static classes fill the conceptual space of a vb module. The var keyword makes variable declaration look more VB's dim. The upcoming dynamic keyword will allow vb-style late binding. Even properties, which is something you could say was "added" to c# for 1.0, are something that vb has had since before .Net.

Answer 2

As a VB.NET developer, here's what I don't like about C#, granted my experience is from reading C#, not writing it so much:

1) No edit and continue. I've seen arguments that Edit and Continue is a bad thing and that it encourages bad coding habits. It reminds me of my project manager telling me 25 years ago that my love of my then-advanced debugger was a "crutch" and that it encouraged bad programming habits. Sorry, I didn't buy it then, I ain't buying it now. At the very least, the advantages outweigh the disadvantages 10:1. Once C# gets this feature, you'll appreciate it more and really appreciate it if you ever have to code without it again.

2) The language is case sensitive. IMHO, this is pure evil. Would people agree that it is bad to have two variables in the same scope that vary only by case? If so, why allow it? Yuck.

3) Background compilation and hence better design-time feedback of errors. A mixed blessing, as this slows down the IDE. But with 2008, performance is better and is probably a time saver. Course, this is not a factor of the language itself, just the dev environment.

4) Braces {}{}. Reminds me of my LISP days where you can tell a LISP programmer from other programmers: They're the ones with their fingers on the screens trying to match up parens.

I find the following VB code easier to read and less likely to contain errors.

If condition1 then
  truestatement1
  truestatement2
else
  falsestatement1
  falsetatement2
end if

If (condition1) then {
  truestatement1;
  truestatement2;
  } //if (cond)
else
  {
  falsestatement1;
  falsetatement2;
  } //else (Condition)

All those braces with lack of auto-indent are just begging for compile time or run-time errors. And as the nested ifs get complex, the braces just add to it. In place of the 4 braces in the C# example, the VB code has just one END IF statement, but C# programmers that comment like to add optional comments as to what block the brace is end bracket is terminating.

The VB code is self documenting with less typing--the IDE even adds the END IF for you when you type in the IF condition line. So, in the end, I am missing the brevity simplicity/benefit here that C#-aficionados claim. The } might be more terse than the End If, but I'm suggesting that the overall structure is unnecessarily complex.

Granted, this all isn't that big of a deal, but as a novice C# coder I feel like it is a lot easier to mess up the nested conditions than it is to use VB.