Decoding the "Managed" Label

 
 
By Peter Coffee  |  Posted 2005-10-03 Email Print this article Print
 
 
 
 
 
 
 

Opinion: Core concepts, not platform branding, should define technology choices.

Like the phrase "Personal Computer" after IBM trademarked "IBM PC" in 1981, the generic label of "managed code" has apparently acquired a vendor-specific aura—as I learned from readers comments on my letter of last week. Many readers, it appears, interpreted that endorsement of managed code technology as a declaration of victory for Microsofts .Net over other implementations of the idea.

Certainly, there are putative definitions of "managed code" that are Microsoft-specific. I stand by my more general usage, though, particularly since Microsoft Distinguished Engineer (and C# designer) Anders Hejlsberg was quite definite in comments two years ago that he considered both Java and Smalltalk to be examples of managed languages.

One reader asked if the benefits that I ascribed to managed code should more properly be credited to object-oriented disciplines. Yes, OO enables better control over interactions among the modules of an application, but I have to disagree with that readers assertion that "encapsulation...can be accomplished in unmanaged [emphasis in original] C++."

No ones ever rebutted the latter statement more colorfully than the editors of "The Unix-Haters Handbook" in 1994, when they wrote: "the objects in C++ are no longer objects when your code is compiled and running. Theyre just part of a continuous hexadecimal sludge. Theres no dynamic type information—no way any garbage collector (or for that matter, a user with a debugger) can point to any random memory location and tell for sure what object is there, what its type is, and whether someones using it at the moment." Even C++ gurus (or perhaps I should say, "especially C++ gurus") are unapologetic about its lack of OO rigor: "The whole design of C++ objects flies in the face of encapsulation since everything depends on the layout of objects. If you add or subtract even a single data member—public, protected, or private—you have to recompile the entire system. What kind of encapsulation is that?", asked "Windows++" author Paul DiLascia in 1999.

Another reader accurately observed, "Managed code encompasses two concepts: storage management, and security management." Thats an excellent point. The storage management benefits of managed code come pretty much for free—thats practically a tautology. The effective use of the security APIs, however, in both Java and .Net seems to me one of the slowest areas of developer community progress on both platforms. If I were responsible for a developer teams training and skills development investments in the coming year, I believe this would be near the head of my list of priorities.

Interestingly, some of the most pointed comments on managed code had more to do with platform politics and tool capability than with the technology itself. As I noted in August, the quality of development tools has everything to do with developers uptake of a language or a platform: as Paul DiLascia said in the same commentary quoted above, "If you were to judge software by the degree to which the design adheres to some internal model of perfection, Windows would surely get the lowest possible score (somewhere below 1 on a scale of 0 to 10). And yet in what system is everyone programming?"

I disagree only with his accompanying assertion that the reason for Windows success is the ability of Windows developers "to write programs that work—programs that are reliable, robust, and easy to comprehend, change, and maintain." Id argue, anytime and anywhere and with anyone, that Windows has succeeded in spite of its flaws in just those areas—because it has consistently offered developers the broadest spectrum of affordable and/or approachable and/or richly platform-aware tools.

As always, I thank the readers whose quick and to-the-point comments give me a chance to clear up any confusion about my meaning, and I invite your further comments on what you want and where youd like to get it—tools, platform features, development management models, whatever—at peter_coffee@ziffdavis.com

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
 
 
 
 
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