In the comments on my post on language choice, Patrick asked “isn’t C# the language that’s most ‘native’ to the .NET environment?” Christopher then follows up with a related question as to whether developers should use functions in the System namespace instead of ones in the Microsoft.VisualBasic namespace because the former might be faster. We see these kinds of questions fairly often, so it’s worth discussing them a little bit.

Before going any further, I’d recommend that people who have questions like this take a look at an article that Derek Hatchard and Scott Swigart wrote for MSDN entitled “Visual Basic .NET Internals”. It looks at a bunch of these issues in detail and is an excellent place to start on this question.

The bottom line, though, is that there is no language that is ‘native’ to the .NET environment. While it’s certainly true that there was no language called ‘C#’ that existed before .NET came into being, one of the major selling points of C# is that it is an amalgm of the syntax and features found in C, C++, Java and VB, adapted for the .NET platform. In that sense, it is exactly like Visual Basic on .NET – an adaptation of a previously existing language (just as C++ and Java were, in turn, adaptations of C, which was, itself, an adaptation of prior languages). Both C# and VB were designed to work well with .NET, and developers can choose either language without any concern about access to the fundamental capabilities of the .NET platform, because they both compile down to IL in the end. The only differences you’re going to see between the IL the two languages generate is when one language does something more for you than the other language does (or we have a bug, in which case, let us know about it).

The question of the Microsoft.VisualBasic namespace is similarly straightforward. The base class libraries (i.e. the System namespace) provide a huge amount of functionality which both C# and VB give you full access to. The functions in the Microsoft.VisualBasic namespace are built directly on top of the System namespace and provide functionality that goes above and beyond the functionality that the System namespace provides. As such, there is no real reason not to use the functions there because they provide you “all the features of the class libraries and more.” (And we’re going to go even further in VB 2005.) Having said that, there may be situations in which you may want to sacrifice some of the extra functionality for a little more performance. This is the same kind of tradeoffs that you have to make with the System namespace, and so if performance is critical, it’s always important to understand the functions that you’re calling (the paper linked to above talks a lot about this).

The problem with blanket pronouncements like “always use CLR functions instead of VB functions“ is that you can easily shoot yourself in the foot without knowing it. One suggestion I’ve seen in more than one place is to use the functions exposed by the Convert class (a CLR class) instead of the intrinsic conversion operators (CInt, CStr, CLng, etc.) exposed by the VB language. This is supposedly because the CLR functions are going to perform better than the VB “functions.” The problem with this is that the conversion operators are true operators that compile down to IL instructions while the Convert functions are still just functions. This means you’ll get significantly worse performance by calling Convert.ToInt32 instead of using CInt. So it’s always very important to know what you’re doing when you start tackling issues like performance.

So, in the end, there is no “native” language on the CLR and performance is something you’re going to have to think about no matter what language you choose. (In fact, I think I should add a rule #0 to my “Ten Rules of Performance:” When it comes to performance, beware rules.) There are certainly lots of other factors to think about when choosing between VB and C#, but I don’t think these are two of them.

Bill McCarthy recently asked me a question that’s come up a number of times both internally and externally: why can’t a Catch or Finally block access local variables declared in a Try block? In other words, why doesn’t the following work?

Try
    Dim i As Integer = 5
Finally
    Console.WriteLine(i)
End Try

There are four answers to the question: the practical answer, the simple answer, the complex answer and the real answer.

THE PRACTICAL ANSWER: The question is moot because changing it now would potentially break code by changing the binding path. For example:

Class Foo
    Private i As Integer
    Sub Bar()
        Try
            Dim i As Integer
            Throw New NullReferenceException()
        Catch
            i = 5
        End Try
    End Sub
End Class

THE SIMPLE ANSWER: Catch and Finally blocks are not children of the Try block, they’re siblings. You can see this by the indentation style and by convention. And the normal scoping rules are that sibling blocks cannot see each other’s locals.

THE COMPLEX ANSWER: You can still say “Yes, but you could still have made an exception in this case, right?” True. However, requiring Catch/Finally variables to be placed outside of the Try block generally results in better code by emphasizing the initial state of the variable (since an exception can occur almost at any time, so the initial state is the only thing you can assume). For example, the following code has a bug — if the File constructor throws an exception, then the Close call is going to throw one too.

Try
    Dim F As File = New File("foo.txt")
    F.Read(...)
Finally
    F.Close()
End Try

THE REAL ANSWER: You may find both of these arguments unpersuasive, which is fine — a quick search on Google quickly found similar debates around Java and I’m sure other languages have them too. The real answer is that it’s a judgment call and certainly one that we’ll probably be arguing about from here until eternity…

Christian notes some differences between the way C# and VB implement interfaces, prompting Peter to ask “Was it accidental or intentional?” The answer is: it was intentional. The exact thought process that lead to the current design is somewhat misty in my memory because it was so long ago, but here’s kinds of how it went:

VB6 supported implicit event handling and interface implementation very similar to the way that C# does implicit interface implementation. You stated that you implement an interface and then you used a “magic name” to implement a method in the interface. When we were designing VB 2002, though, we wanted to allow people to handle multiple controls’ events with a single handler. The magic name design for event handling would have effectively prevented that, because there was no reasonable “magic” name that could mean “hook me up to x.Click and y.Click.” (C# obviously doesn’t have this problem since they don’t support declarative event handling.) So we decided to drop magic naming for event handlers in favor of an explicit Handles clause that allowed multiple events to be handled.

Once we’d taken that step, we decided we liked the new explicitness of event handling and decided that it would work for interface implementation as well. It meant that we could get rid of clunky VB6-style magic names (i.e. “Sub IDisposable_Dispose(…)”) entirely and also meant that a single class member could implement multiple interface members, although so far I don’t know of many places where that comes in super-handy (since most interfaces are, by nature, discrete from one another). Also, because it didn’t rely on magic names, there was no chance that you might “accidentally” implement an interface member without realizing it.

So that’s the story.