C# Standards: Why? How? So What?
I've said before that I think the coolest part of the upcoming Visual Studio.NET is C#. It's a lean, clean language. C++ and Java developers will feel right at home in it, and VB programmers won't be intimidated by it. It's a power tool for the masses; I'd be surprised if it doesn't become the VS.NET RAD tool of choice.
That, apparently, is not good enough for Microsoft.
As you probably know, Microsoft has submitted its C# specs to ECMA (www.ecma.ch) for review. Once ECMA has reviewed, chewed, and approved them, C# belongs to the world. Anybody can (and probably will) port the language to any platform, opening the door to developing C# for Macs, Linux, Web browsers, Palm OS—you name it.
But why? It's not too hard to think of reasons—some earnest and noble, some less so—that Microsoft would want to have C# available on other, non-.NET platforms:
It's a truly cool language. Anders Hejlsberg and company have knocked themselves out writing a powerful, forward-thinking language without a lot of legacy language baggage. Microsoft unselfishly wants to share it with the world. Isn't that reason enough? No, I don't think so, either.
They want you to use it. Microsoft knows that cool isn't enough—in order to get developers to once again climb the new language curve, they'll need to be able to use the language outside the Windows environment. The more widespread the application, the more likely you are to buy into it.
Portability. Of course, any apps you write in C#—even ones not for Windows—are going to port pretty darn easily to .NET. One way or another, Microsoft's gonna getcha.
To twist the knife. A while back, Sun submitted Java to ECMA—then retracted it because it wanted more control over the process than ECMA would give. By allowing C# to run through the normal standardization course, Microsoft shows the world who really has a portable, open language.
The "How": It's not like you can just ring up ECMA and ask them to make your language a standard. According to Jan van den Beld, secretary general of ECMA, "First, an ECMA member company submits a proposal with its initial language spec. Next, other member companies—presumably ones that have an interest in the language—join a review committee. Together, they write the standard. The standard should leave enough room for competing implementations. They arrive at their final result by means of a consensus process in an ECMA Technical Committee."
And if someone wants to build a version of C# without bothering with the committee? Fine. Says van den Beld, "The ECMA standards are not mandatory, either for nonmembers or members." He adds that ECMA doesn't verify an implementation's standards compliance. So, just as there are innumerable variants of C++ floating around, we can expect all kinds of C# flavors to appear, with wildly different degrees of compliance.
But do you care? There are questions about the standardized C# I can't answer. Microsoft and van den Beld can't answer them either. Only developers—you—can answer them. So tell me:
Is the ECMA-standardized C# important to you? Or do you think C# is a compelling enough language on its own?
Does having C# available on other platforms make a difference to you? In what way?
What's the biggest advantage to having C# standardized? The biggest drawback?
Enough, already? One more question: Do you plan to develop using C# (regardless of standardization)? Or are you sticking with C++ and wish I'd stop harping about C#? Send me e-mail (vcdjedit@fawcette.com) and tell me whether you think the "C" in VCDJ should stand for both
C++ and C#.
