Deferred Surprises in .Net Development

By Peter Coffee  |  Posted 2002-02-25 Print this article Print

Peter Coffee: .Net's Common Language Interface restrictions are tighter than you might think.

In my last newsletter, I discussed the limits of the Common Language Infrastructure at the core of the .Net promise of language-neutral programming; some readers accused me of beating up on Microsoft without any real reason. Within that same week, however, I discovered that the limits of the CLI are even tighter than I had previously realized, and that .Net descriptions have been a little casual about crucial details in this area. My colleague Timothy Dyck got me started down this trail with his pointer to a technical discussion of CLI constraints. I was startled to find, in that analysis, a reference to something called "Eiffel#"—not the full-blown Eiffel, one of the best implementations of software engineering principles yet to be realized as a workable high-level language, but the CLI-compatible variant that turns out to lack some important Eiffel features.
My surprise was due to the numerous times that Microsoft has mentioned Eiffel (without the "#") as a poster child for independent support of the .Net platform. They fooled me: Ive mentioned Eiffel in that context myself, in my previous newsletter and on several other occasions, as have other independent observers.
You can find the real story, several layers down, on the Eiffel language Web site, where its progenitors disclose the compromises in Eiffel#—including significant limits on inheritance. Whether or not you care about Eiffel in particular, I hope that these references make it clear that Im not hearing monsters under the bed—and that claims of platform openness continue to demand close scrutiny. Speaking of close scrutiny, however, I also want to point you to my revised version of my lengthy review of Microsofts Visual Studio .Net that appeared in last weeks print edition of eWEEK and on the Web concurrently with the products launch the week before. I broke one of my own long-standing rules in that review: I said that there was something the tool couldnt do, when Ive known for more than a decade that some developer has always found some way to make any given tool do anything that mattered enough to a project. Specifically, I said that the source code editor in VS .Net could not drive the visual form designer, but that the linkage only went the other way—producing automatically generated code that came with a stern "hands-off" warning. Actually, there is a link from manual code modification back to the visual UI editor, but it is deferred: Changes only take effect the next time the visual tool comes to the foreground, and inconsistencies arent hard to create, but I erred in calling the link "one-way." The online version of the review and the separate online walk-through of the product have both been updated to reflect this subtlety. Thanks to the alert and thoughtful eWEEK readers who urged me to clarify this. Its clear that Im not the only one whos watching closely for other deferred surprises in .Net: When I asked readers of my review what most concerned them about the process of evaluating the new Visual Studio package, the prospect of "undesired coupling between Web standards and Microsoft protocols" received a majority (not just a plurality) of the more than 800 (admittedly, unscientifically sampled) responses. Its not an indictment, just an expression of interest on the part of developers and their managers who are already daunted by the size of the step that theyll have to take just to get up to the drivers seat and embark on their journey to Web services. E-mail eWEEK Technology Editor Peter Coffee
Peter Coffee is Director of Platform Research at, 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