Bob On Development

I have just embarked on a VB.NET project … not normally my first choice, but not a huge deal either. Some day when I’m feeling contentious I may dive into my take on the whole perennial C# vs VB.NET thing, but for now, I want to focus on just one limited facet of that debate.

C# was a new language in 2002, introduced with .NET. At that point it had zero backward compatibility baggage … an advantage that is by definition gradually oozing away ever since but still holds basically true.

On the other hand VB.NET, while it is a substantial departure from VB6 and its predecessors, still does hand-stands to provide a comfort zone to legacy VB developers. So you have, for instance, the Left(), Right() and Mid() functions in the language. C# lacks these because it doesn’t need them; String.Substring() handles all that just fine. Nothing prevents you from using String.Substring() in VB.NET, but nothing encourages you to do so, either.

I’m still trying to decide whether this is a Good Thing or not. Maybe in the Great Scheme of Things it isn’t that big of a deal. Iron Python, for instance, or Eiffel.NET, or COBOL.NET will certainly have to preserve legacy structures that duplicate .NET functionality, and they should, or else getting legacy code ported to .NET would be more of a pain than it’s worth.

The thing is, something offends my sense of order when these features are used on brand new code. To me, the key to working in .NET is to know the .NET class libraries (or API, if you will). If you know that you can write code in any language that anyone should be able to understand.

In addition, legacy language constructs tend to have their own little odd behaviors and ways of handling errors and boundary conditions differently. Drill down into the details of, for instance, CType() vs DirectCast() and you’ll find that DirectCast() is the exact equivalent of the C# cast operator, whereas CType() is not exactly the same thing … it has certain implicit behaviors; that’s why DirectCast() got the name that it has.

My thinking is that if you see DirectCast() used in VB.NET code, you know exactly what it does, whether or not you have been a VB jockey all your life. If on the other hand you’re an old pro at VB, you may or may not be fully aware of the nuances of how CType() works. Legacy VB was so forgiving, and that was one of its virtues. If you run with certain compile time options, it still is. Which brings up another point; I haven’t verified it but would be surprised if your use of Set Strict or Set Explicit influences the behavior of calls into non-legacy BCL methods. Just one less variable to deal with.

I suppose it all boils down to how much of a religion you want to make out of VB vs. .NET. Clearly, it’s up to you, the developer, how broad or parochial a view you want to take of these things. My personal tendency is to avoid legacy language constructs except when they aid porting. It generally makes perfect sense to disturb legacy code as little as possible. Other than that circumstance, though, why not speak a more universally-understood dialect and be a more congenial member of the .NET technology world?

On the other hand if you work with a VB-centric shop and you introduce a bunch of constructs that are unfamiliar to them, you may encounter Political Problems and then you may have to pick your battles.

It will be interesting to see what kind of reaction I get to my .NET-centric maintenance work on this non-legacy project which nonetheless is heavy on legacy VB contructs. I figure that it’s easier to ask forgiveness than to get permission, but if it ruffles too many feathers, I’m prepared to dust off my old VB skills and backtrack a bit.