C# Strengths Arent Enough Without Developer Smarts

By Peter Coffee  |  Posted 2002-12-30 Print this article Print

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.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel