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