The Big Mistage of VB.NET

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).