C# Strengths Arent Enough Without Developer Smarts

Peter Coffee: Tools' potentials go unfulfilled if technical perspectives are ignored.

Thinking back over 2002, strictly from a developer perspective, it seemed to me that the biggest dog that isnt barking is C# ("C sharp"), arguably the native language of the .Net platform.

For Windows developers, C# offers most of the strengths of Java while retaining more access (for good or ill) to programming models that are deeply rooted in the C++ community. With Microsofts weight behind it, especially as expressed in the Visual Studio .Net tool set, I wondered why Id found it so easy not to think more often about C# since its debut almost two years ago.

My memory was jogged by a comment by Rich Murphy, Microsofts program manager for the companys Project product line, when I spoke with him in November. The current version of Project, he explained, was a .Net application but was written the hard way, in C++, because Microsoft could not be certain that Visual Studio .Net would ship in time to meet the product teams needs. Future versions of Project, he said, would be written in C#, as would other Microsoft .Net-based offerings.

Theres the first clue to the lack of barking: Its too soon for C#, as an ecosystem of complete and proven tools, to have gotten major traction in efforts of substantial size. But those tools are clearly coming, and I dont just mean the April launch of the next Visual Studio .Net release (already available for final-beta download).

If camels could bark, I wouldnt have to mix a metaphor in the next sentence, but so be it. The second clue to the lack of barking may be the camels nose of continued C# evolution that stuck itself into developers tents at the beginning of November, when Microsoft announced four significant changes that it will propose to the language--and that it apparently plans to offer in the Yukon version of Visual Studio .Net.

Microsoft documents describe plans and rationales for C# versions of generics, enabling higher level re-use of code; iterators, for type-level declaration of operations over the members of a collection; anonymous methods, a tool that I grew to love as a Lisp programmer, to encapsulate behaviors; and partial types, a facility for dividing type definitions into several files (easing the separation, for example, of code written by a developer from code automatically emitted by software).

I hope that I correctly hear you asking the immediate question, "What about the ECMA standard?" Well, of course, say the company announcements cited above, the April 2003 version of Visual C# .Net will be fully compliant with the December 2001 ECMA 334 standard for the language, and Microsoft "intends to submit" the proposed new features to "the ongoing standards process for the language."

Is "ongoing" really the correct word? Or would "ever-pursuing" be more descriptive?

To be fair, Microsoft is not the only party still busily stirring the C# pot (for metaphor spotters, that was #3). Just this month, a proposal for simplifying C# property syntax surfaced in a developer discussion forum.

My reaction to this proposal in particular, and to proposals of this kind in general, is that its much more important for code to be easy to read than it is to be easy to write, and that the general case shouldnt look wildly different from the most common special case. But what can you expect from someone who likes (actually likes!) both Lisp and Ada?

In fact, I like having many languages available that each fit different needs well. "Having lots of programming languages in my bag of tricks is just one part of being a good programmer," agreed the estimable David Intersimone of Borland in his comments two years ago on whether the world really needed C#. Another answer to that question comes from Michael Perry of Mallard Software Designs, who has suggested that "Java fails to meet the goal of providing access to platform-native resources" and that "no existing language supports COM as comprehensively as C# does."

Regardless, though, of our technical likes and dislikes, or even our hopes and skepticisms, we should go into 2003 with the goal of making our best judgment more effective in actually guiding enterprise projects. "In the overall scheme of things, when it comes to decision making power, programmers are at the bottom of the food chain, whether the issue is technical or not," warned Atlanta-based development guru Christopher Duncan in his comments this month on the C# Corner forum. "We need to build credibility with those who have the power to effect change," Duncan added; "we need them to know that were looking out for their personal objectives."

Lets not become so focused on the political battles between Microsoft and Sun, for example, that we fail to notice--let alone win--the ones that are closer to home.

Wishing you a prosperous 2003.