Questions and Answers About C#
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
C# is one of the most visible aspects of Microsoft's .NET initiative. Developers commonly see the world through the lens of their language, and so C# can be their main aperture into .NET. Misconceptions abound, however. In this article, I'd like to address the confusions I hear most often about this new tool.
Which is better: C# or Java? The two languages have an awful lot in common, and so in some ways it's natural to try to choose a winner. The fact that each language is often viewed as the flagship of its camp—C# in Microsoft's .NET environment, with Java supported by everybody else—makes the comparison especially attractive. But it's the wrong question. Not only is there no objective answer, it wouldn't matter if there were. To see why, realize that both languages are in fact embedded in a much larger matrix of technologies. Using C# requires using the .NET Framework, including the Common Language Runtime (CLR) and the .NET Framework class library. Similarly, using Java requires using a Java virtual machine and some set of Java packages. The choice implies an enterprise vendor decision as well: C# means Microsoft (today, at least), whereas Java means IBM or BEA or some other non-Microsoft choice. Deciding which of these paths to take based solely on the language is like buying a car because you like the radio. You can do it, but you'll be happier if you choose based on the whole package.
Isn't C# just a copy of Java? In some ways, yes. The semantics of the CLR are quite Java-esque, and so any CLR-based language will have a good deal in common with Java. Creating a language that expresses those semantics in a syntax derived from C++ (for example, C#) is bound to result in something that looks a good deal like Java. Yet there are important features in C# that don't exist in Java. One good example is support for attributes, which allow a developer to easily control significant parts of her code's behavior. In .NET, attributes can be used to control which methods are exposed as SOAP-callable Web services, to set transaction requirements, and more. Still, if Microsoft had been free to make some changes to Java, my guess is that C# wouldn't exist today.
Isn't C# the native language of .NET? Every language built on the .NET Framework must use the CLR. The CLR defines core language semantics, and so all of the languages built on it tend to have a great deal in common. The biggest choice a .NET compiler writer has is the syntax his language will use. Microsoft needed to provide a natural path to the .NET Framework for both C++ and Visual Basic developers, and so the company created C# and Visual Basic.NET. Yet the facilities these two languages offer are nearly identical—C# can do just a little bit more—and so neither is the "native" .NET language. There is no such thing.
But won't most .NET developers eventually choose C# over Visual Basic.NET? No. Because the power of the two languages is so similar, the primary factor for developers migrating to the .NET world will probably be the syntax they prefer. Since many more developers use Visual Basic today than C++, I expect that VB.NET will be the most popular choice. For the vast majority of VB developers who are fond of VB-style syntax, there's no reason to switch to C#. I believe that the dominant language for building Windows applications five years from now will still be Visual Basic.
Will we eventually see a .NET Framework-based version of Java as a competitor to C#? Apparently not. Microsoft will never offer a complete Java environment because Sun has essentially required that Java licensees implement all of Java—something Microsoft will never do. (Why should it? Does anyone expect Sun to implement C#, VB.NET, and the .NET Framework?) And if a Java aficionado chooses to use a CLR-based Java compiler, such as the one included with Microsoft's JUMP for .NET technology, she's unlikely to be truly happy. Java implies a series of Java libraries and interfaces, such as Swing and Enterprise JavaBeans. The .NET Framework provides its own equivalent technologies, and so most of these won't be available. As a result, a developer using the Java language on the .NET Framework won't feel like she's working in a true Java environment because the familiar libraries won't be there.
C# is probably the most important new programming language since the advent of Java, and it will be used by many developers. But it may have gotten more attention than it deserves, if only because focusing on this new language tends to obscure the many other important innovations in the .NET Framework. Take it seriously, but don't think it's the main event in the new world of .NET.