Opinion: Core concepts, not platform branding, should define technology choices.
Like the phrase "Personal
after IBM trademarked "IBM PC" in 1981, the generic label
of "managed code" has apparently acquired a vendor-specific auraas 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
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
informationno 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 memberpublic, protected, or privateyou
have to recompile the entire system. What kind of encapsulation is that?", asked "Windows++"
author Paul DiLascia
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 freethats practically a tautology
effective use of the security
, however, in both Java
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
, 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
I disagree only with his accompanying assertion that the reason for Windows success is the ability of Windows developers "to write programs that workprograms 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 areasbecause 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
, whatever—at email@example.com
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.