Columns

C#: It’s the Components, Stupid!

• By David Chappell
• August 21, 2001

The initial take on C# has been that it is a sour grapes response to Sun’s refusal to let Microsoft have its way with the Java language. There is probably at least some truth in this, although the Sun/ Microsoft lawsuit over Java has yet to reach the end of the road. Whatever happens, and however successful C# may prove to be, Microsoft will be at a disadvantage if it can’t somehow support the Java language. Plenty of development organizations want to use Java, and an armada of new computer science graduates is sailing into the workplace with Java embedded in their nervous systems. If Microsoft can’t find some way to please the biases of these developers, its competitors surely will.

But thinking of C# as purely a response to Java misses a critical point. An important part of the language actually grows out of the Component Object Model (COM) or, more correctly, the ongoing work on COM+. Microsoft’s initial COM+ announcement, made several years ago, envisioned an integration between programming languages and component technology that went well beyond what COM provided at the time.

In the first release of COM+, which shipped in February of this year with Windows 2000, Microsoft didn’t come anywhere close to realizing this vision. Instead, it chose to focus on the much simpler task of integrating COM more completely with the Microsoft Transaction Server (MTS), as well as adding a few other new COM-based technologies. But with the arrival of the .NET initiative, the goal of integration between language and components laid out so long ago has finally arrived.

What does all of this have to do with C#? When Microsoft first outlined its grand COM+ vision years ago, it was apparent that achieving it might require significant changes to the programming languages involved. Microsoft owned Visual Basic, so that language presented no insurmountable problem, and Java is intrinsically such a good fit with COM that it didn’t present many difficulties. The hard case was C++. Microsoft even talked about unilaterally modifying this allegedly standard language to fit its new component vision, a prospect that sent proprietary shivers down the spines of a number of people (including me).

The reality has turned out to be somewhat different. Rather than making the drastic changes in C++ required to fit it naturally into the .NET conception of components, Microsoft created C#. The Common Language Subset (CLS) that is at the core of .NET components is also at the core of C#. While Java would also likely have been (and may yet be) a fine language choice for working in this new component world, C# is designed for exactly this purpose. Absent Sun’s lawyers, Microsoft may never have felt the need to create C#. Given the world as it is, however, it’s not correct to view this new language as purely a Java knockoff. The advances in component technology that Microsoft has been promising us for some time have also been a major factor in the language’s design.

Making a new language popular is incredibly difficult. The landscape of the past 25 years is littered with the carcasses of dead programming languages, all of which had something to recommend them. The ascendancy of Java is almost a miracle, riding as it did on the crest of the Internet wave. If Microsoft’s only goal were to create a countervailing force to the Java language, it’s hard to imagine that C# would be likely to escape the usual fate of new languages. Yet because it is tied so strongly to Microsoft’s component technologies, I would rate the odds of its success significantly higher.

If nothing else, it may quiet the critics who berate C++ for being too hard and Visual Basic for being too ugly. C#, especially with its built-in affinity for components, looks to be neither of these things.¹