The Philosophy of .NET

Life As a Java/J2EE Programmer
Enter Java. The Java programming language is (almost) completely object oriented and has its syntactic
roots in C++. As many of you are aware, Java’s strengths are far greater than its support for platform
independence. Java (as a language) cleans up many unsavory syntactical aspects of C++. Java (as
a platform) provides programmers with a large number of predefined “packages” that contain various
type definitions. Using these types, Java programmers are able to build “100% Pure Java” applications
complete with database connectivity, messaging support, web-enabled front ends, and a rich user
interface.
Although Java is a very elegant language, one potential problem is that using Java typically
means that you must use Java front-to-back during the development cycle. In effect, Java offers little
hope of language integration, as this goes against the grain of Java’s primary goal (a single programming
language for every need). In reality, however, there are millions of lines of existing code out
there in the world that would ideally like to commingle with newer Java code. Sadly, Java makes this
task problematic.
Pure Java is simply not appropriate for many graphically or numerically intensive applications
(in these cases, you may find Java’s execution speed leaves something to be desired). A better approach for such programs would be to use a lower-level language (such as C++) where
appropriate. Alas, while Java does provide a limited ability to access non-Java APIs, there is little
support for true cross-language integration.

Life As a COM Programmer
The Component Object Model (COM) was Microsoft’s previous application development framework.
COM is an architecture that says in effect, “If you build your classes in accordance with the
rules of COM, you end up with a block of reusable binary code.”
The beauty of a binary COM server is that it can be accessed in a language-independent manner.
Thus, C++ programmers can build COM classes that can be used by VB6. Delphi programmers
can use COM classes built using C, and so forth. However, as you may be aware, COM’s language
independence is somewhat limited. For example, there is no way to derive a new COM class using
an existing COM class (as COM has no support for classical inheritance). Rather, you must make use
of the more cumbersome “has-a” relationship to reuse COM class types.
Another benefit of COM is its location-transparent nature. Using constructs such as application
identifiers (AppIDs), stubs, proxies, and the COM runtime environment, programmers can
avoid the need to work with raw sockets, RPC calls, and other low-level details. For example, consider
the following VB6 COM client code:
' This block of VB6 code can activate a COM class written in
' any COM-aware language, which may be located anywhere
' on the network (including your local machine).
Dim c as MyCOMClass
Set c = New MyCOMClass ' Location resolved using AppID.
c.DoSomeWork

Although COM can be considered a very successful object model, it is extremely complex under
the hood (at least until you have spent many months exploring its plumbing—especially if you
happen to be a C++ programmer). To help simplify the development of COM binaries, numerous
COM-aware frameworks have come into existence. For example, the Active Template Library (ATL)
provides another set of C++ classes, templates, and macros to ease the creation of COM types.
Many other languages also hide a good part of the COM infrastructure from view. However, language
support alone is not enough to hide the complexity of COM. Even when you choose a relatively
simply COM-aware language such as VB6, you are still forced to contend with fragile registration
entries and numerous deployment-related issues (collectively termed DLL hell).

Life As a Windows DNA Programmer
To further complicate matters, there is a little thing called the Internet. Over the last several years,
Microsoft has been adding more Internet-aware features into its family of operating systems and
products. Sadly, building a web application using COM-based Windows Distributed interNet Applications
Architecture (DNA) is also quite complex.
Some of this complexity is due to the simple fact that Windows DNA requires the use of numerous
technologies and languages (ASP, HTML, XML, JavaScript, VBScript, and COM(+), as well as
a data access API such as ADO). One problem is that many of these technologies are completely
unrelated from a syntactic point of view. For example, JavaScript has a syntax much like C, while
VBScript is a subset of VB6. The COM servers that are created to run under the COM+ runtime have
an entirely different look and feel from the ASP pages that invoke them. The result is a highly confused
mishmash of technologies.
Furthermore, and perhaps more important, each language and/or technology has its own type
system (that may look nothing like another’s type system). An “int” in JavaScript is not quite the same
as an “Integer” in VB6.