Choosing a .NET Language
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The .NET Framework supports many different programming languages. Microsoft's Visual Studio.NET provides C#, Visual Basic.NET, and others, while third parties promise to give us even more choices. Still, it seems all but certain that C# and VB.NET will be the dominant languages in the .NET world. They'll have the most books and courses available (and so will be easiest to learn), and they'll also have the most documentation and sample code available from Microsoft. Although other .NET Framework-based languages will likely appeal to pockets of users, C# and VB.NET will dominate.
So, which one should you learn? In spite of what I just said, I believe that you shouldn't choose either C# or VB.NET. Here's why.
In traditional programming languages, the language designer was free to specify both the syntax and the semantics (that is, the behavior) of a new language. As a result, learning any language meant learning how that language addressed these two areas. In the .NET Framework, however, this traditional split is no longer present. Instead, the Framework's Common Language Runtime (CLR) specifies a large part of how a language functions. The creator of any CLR-based programming language has carte blanche for syntax, but an enormous part of the language's semantics is out of her hands.
A key part of the restrictions on a .NET language designer is the CLR's Common Type System (CTS). The CTS specifies the behavior of a large set of types, and a language built on the CLR generally just exposes those types in whatever syntax it chooses. The list of things the CTS covers is long, and it includes the following:
Simple types such as integers and floating-point numbers
More complex types such as interfaces and structures
Delegate types for safely passing references to methods
Rules for defining and using exceptions to handle errors
Much more
Most important, the CLR also defines the behavior of those types: How does inheritance work? Which types can implement an interface? What features do exceptions support? These and many other fundamental aspects of a language are specified by the CLR.
Yet the CLR says nothing at all about a language's syntax. What loops and if statements look like, how variables are declared, whether curly braces are used, and everything else about how the language looks are entirely up to the language designer. So although the designer can choose what a class declaration will look like, for example, she has little freedom in specifying how that class behaves.
For the most part, this is a good thing. The semantics of the CLR are powerful, modern, and well-thought-out. What's the value in having multiple languages with very similar (but not identical) semantics expressed in diverse syntaxes? Developers get very attached to syntax, so why not provide syntactic choice on top of common behavior? This deep similarity among .NET Framework languages is all but mandated by the CLR.
And this is exactly why you shouldn't learn either C# or VB.NET. Instead, you should learn both. After all, their underlying semantics are virtually identical. A class in VB.NET has the same features and the same behavior as a class in C#—as do structures, interfaces, and other types. Also, both languages rely heavily on the .NET Framework class library for creating GUIs, building Web applications, working with XML, accessing databases, and lots more. Beyond a few relatively minor differences, such as C#'s support for operator overloading and the creation of type-unsafe code, the two languages are semantically the same.
The hard part of learning a language isn't learning its syntax. Any decent developer can learn a new syntax very quickly. The hard part is understanding the details and idiosyncrasies of the language's behavior. Yet once you learn VB.NET, you've also learned the underlying semantics of C#, and vice-versa. All that's left is to come to grips with the alternative syntax. Learning one language or the other will take some time, certainly. But once you've made this investment, learning the other is simple.
Ultimately, there's little point in learning only VB.NET or only C#. The extra investment required to understand both is minimal, and the payoff is likely to be great.