After what I wrote yesterday, I came across PaulV's comments on the same subject:

So, in the end, I think the whole "C# vs VB" argument is a non-starter. The real question is: are we doing a good job making your life easier? Are we the best tool for developers out there? That's the important thing and what we focus on every day.

Panopticon Central: Essentially, if you know that what you're converting is exactly what you say it is, then you can use DirectCast to bypass the little bit of overhead that you incur by using the runtime helper.

So even though a lot of C# developers wish VB would just go away, it's not going to happen. [Sean 'Early' Campbell & Scott 'Adopter' Swigart's Radio Weblog]

I'm looking forward to the feature divergence between C# and VB.NET that will no doubt begin next year. I think that will make a lot of the arguments disappear. I'm all in favour of picking the right language for the right task - surely that's what the language agnostic Common Language Runtime is all about. It's tough at the moment to choose between C# and VB.NET while the discernible differences are small.

From what I've read, the idea is that as time goes by, C# will develop more complex functionality that more naturally sits with the brace-language crowd whilst VB.NET targets the more RAD approach and keeping things simple.

The problem is that this falls down in some areas at the moment. Let me give an example. I'm currently involved in an n-tier VB.NET project and as such we have a namespace hierarchy reflecting different application areas and different tiers. To hide some complexity from VB.NET developers, the projects have a default namespace to save having to make namespace declarations in each file. If you declare a namespace it prepends the default namespace to the name you have declared (e.g. if you default namespace is Company.App and you declare Namespace Internal then classes here will be in Company.App.Internal). I'm sure in the long run this causes more namespace confusion than it solves. We've actually run across an issue where VS.NET Intellisense will allow you to drill down into a namespace to reference a class only to then discover that the code it helped you type won't compile because of the way the default namespace affects name resolution in code. I'm sure it would be easier to explain namespaces to a new developer than it is to explain how the compiler finds classes using the default namespace (which seems a bit of a mystery anyway).

simplegeek: I once talked to a guy that ran a game development company. He talked about the artists that he employeed. Developers, he said, saw problems as black and white - you either solved the problem or you didn't. Artists, however, see problems as red and blue. Neither is right or wrong, rather one is red and one is blue. The key, he continued, is to never have a red/blue person work for a black/white person.