Java And Dot Net Philosophies

An account from the early days...

I have spent the last ten years as an independent consultant, architecting and building systems on both the MicrosoftWindows and UnixOs platforms (with the occasional mainframe or midrange platform thrown in). I had primarily developed software with Microsoft tools and developed databases with Oracle or SqlServer.

Then Java caught my attention. As I investigated it, I realized that Java was where I wanted to be. I switched to Java when I became convinced of its enterprise maturity.

However, the economy has driven me to take an IT staff job (as a Senior SoftwareEngineer, supposedly). Now I am back in the Microsoft world developing an enterprise system using DotNet and CeeSharp. Now I am five months into that project, having started just after DotNet went final.

What I have found is that the Windows and Unix platforms are more that just competing products - they represent competing philosophies.

The Unix platform is founded on the premise that the user demands, and can handle, control of their systems. The platform provides a toolbox full of simple tools that are easy to configure and combine. The user has complete control to mix and match individual tools to create their own solution. The user also has complete responsibility to deal with all the issues that arise in the process. Most of the tools are free or nearly free, as is most of the help. The only real hindrance to the user achieving their desired results is their own competence, imagination, and resourcefulness. No obstacle has to be a show-stopper. However, most of the available tools and assistance require significant effort by the user to apply properly. Most of the user's resources are focused on design. [The Unix philosophy is nicely presented in TheArtOfUnixProgramming by EricRaymond.]

The Windows platform is founded on the opposite premise that the user does not want, and refuses to accept, control of their systems. The user chooses from a small set of off-the-shelf products, each of which provides a major piece of their desired results. Each product requires significant effort to install, configure, and coordinate with other products, but there are people available to handle those responsibilities. With minimal competence, imagination, and resourcefulness, the user can easily accomplish most of their desired results. Most of the issues that arise can be easily directed to the appropriate product manufacturer. Sometimes the manufacturer can provide no resolution, but that is uncommon. Most of the user's resources are focused on acquiring and managing a few crucial products.

Although I definitely prefer the Unix philosophy, I believe that neither philosophy is inherently better to the degree that it can successfully exclude the other. There will always be sets of competing products, platforms, and approaches that reflect these two philosophies.

Java arose from and reflects the Unix philosophy. DotNet obviously arose from Microsoft, but it begins to depart from the Windows philosophy. Unfortunately, the partial departure may be what kills it (more on that later). Since there will always be people who pursue each of the Unix or Windows philosophies, there will always be room for products, platforms, and approaches that reflect each one. DotNet will not kill Java because DotNet is irrelevant to those people who pursue the opposite philosophy, and vice-versa.

As for DotNet's departure from the Windows philosophy, I find that DotNet adopts many of the characteristics of the Unix philosophy as exemplified in the Java platform. DotNet is much more of the mix-and-match-lots-of-little-components than Microsoft's previous approaches. DotNet is less monolithic, less GUI-centric, more easily-configured-and-deployed-pieces, more tool-agnostic, etc. However, DotNet still keeps some critical footholds in the Windows worldview.

DotNet claims multilanguage support, but actually doing it is a programmer's nightmare of constraints, incompatibilities, and partially documented gotchas. Likewise, it claims to preserve the legacy code investment, but even porting pre-DotNet VisualBasic is nontrivial.

DotNet claims platform portability, but Windows-specific functionality is embedded in the core libraries. For example, System.Environment provides information regarding the OS, machine, and user, but it presumes a Windows platform. Other parts of the DotNet core libraries presume interaction with IIS or some other Windows product or subsystem. System.Data.SqlClient constitutes the SqlServer database client; I have a problem with upgrading my core development platform just because I need to upgrade my database driver. Including the SqlServer database driver in the core libraries seems inappropriate anyway.

Microsoft does not require you to use VisualStudio, but it is not yet easy not to do so. The Java platform makes it easy to mix-and-match your JavaVirtualMachine, compiler, IDE, etc. Microsoft is only just beginning to get there. For a truly enterprise project, I have found that you will need to do so since VisualStudio is not up to the task.

But the one thing that I find most distinguishes the two philosophies, and the two platforms, is the differences in their documentation. I have found that the Windows philosophy has always limited the documentation, both internal and external, to a tool-centricity. The Unix philosophy, especially as exemplified by the Java platform, has expanded the documentation to be design-centric. The DotNet documentation, and the third-party documentation available as web sites and books, have only begun to embrace the importance of design. Microsoft et al. now speak of architecture, tool choice, SeparationOfConcerns, and other such crucial design issues, but only minimally so and in a naive fog. When I first encountered documentation regarding Java, and especially today as I continue to explore such resources, I am inspired by the focus on design. Most Java-related documents start at a level of design sophistication that very few Microsoft-related documents ever achieve. Microsoft-related authors seem to hope that their readers may eventually become competent with their basic tools and then graduate into designers; Java-related authors seem to (properly) presume that their readers are already competent with their various tools and expect them to be designers already. I have said more about the underlying concepts at ProgrammingIsInTheMind and MicrosoftProgrammerMentality.

Beyond the philosophical issue, I have found many issues with the DotNet platform. Most of them can be attributed to its youth. Java has what I need and want, but DotNet has not matured yet. I need transaction management, but DotNet does not have it (Microsoft says to use ComPlus, but then you are outside of DotNet). I need a distributed object solution, but I am left on my own to figure out DotNetRemoting. I need a clean approach to build a web site (comparable to JavaServlets), but Microsoft provides only AspDotNet. I want an EnterpriseApplication server (comparable to an EnterpriseJavaBeans container), but nothing is on the horizon. Meanwhile, Microsoft constantly contradicts itself, such as in recommending that DataSets? be used to carry data from the database all the way to the GUI, and then pointing out that such an approach violates the design principles of a multitier system.

Overall, there are things that I very much like about DotNet that I see as improvements over the JavaPlatform. However, they are minor compared to the immaturity of and the underlying philosophy of DotNet. Maybe DotNet will grow up to be a beautiful thing, but I would not promise it.

-- RobWilliams

Re: "I need transaction management, but DotNet does not have it (Microsoft says to use ComPlus, but then you are outside of DotNet). I need a distributed object solution, but I am left on my own to figure out DotNetRemoting."

These are both sort of anti-RDBMS problem-solving approaches. And SeparationOfConcerns is an overused buzzword in my opinion and has its own downsides and alternatives. One of the few things I credit Microsoft for is only embracing fads partially, waiting for them to be proven, or at least not dangerous, before plunging all the way. --AnonymousDonor

ItJustWorks encapsulates MicrosoftWay.