Microsoft’s .Net is quickly becoming, if it is not already, the dominant development tool, for lack of a better word, for the Windows platform. For the uninitiated, "Microsoft® .NET is a set of software technologies for connecting information, people, systems, and devices. This new generation of technology is based on Web services-small building-block applications that can connect to each other as well as to other, larger applications over the Internet." It is MS’s answer to Java. Where Java has byte code, .Net has Intermediate Language. Where Java has a JVM (Java Virtual Machine), .Net has the CLR (common language runtime). There are numerous organizations migrating to .Net, some even from the Java world. But is this a good choice? On the surface, you gain a good degree of security from the built-in garbage collection and memory management, reusable components that will reduce the amount of coding necessary for a given project, and a great development tool. But are these pluses worth it? I would posit that they are not.

Those of you who know me know where I currently work. In order to avoid associating them with ideas with which they may not agree, I won’t name them. Instead, we’ll say I work for Widgets, Inc. Here at Widgets, we rely heavily on IBM’s iSeries machines. We have a plethora of legacy RPG code and seemingly innumerable files, tables, spool files, CLs, and so on. Fifteen or twenty years ago, the decision was made to run the enterprise of the iSeries (then known as the AS/400). At the time, the dominant language on the iSeries was RPG (for reasons that I don’t know), so all of the custom coding was RPG code. At the time, it made perfect sense.

Let’s fast forward, now, to 2002. RPG programmers are hard to find, and can tend to be expensive. That being so, the management of Widgets, Inc. decide to do all new coding in Java instead of .Net. This gave us access to modern technologies, and hordes of developers. A year and a half later, though, after some small- to medium-sized projects, we reversed our decision because user interfaces are easier in .Net. Choosing ease of development (an edge that Java will soon remove with JavaServer Faces), we have set the ball in motion for RPG, episode two.

How, one might ask, does .Net compare to RPG? For the longest time, companies making investments in iSeries and RPG-based technologies could rest assured that they were making a wise investment, one that would continue to make business sense for a long time. Over the years, however, the iSeries began to decline in popularity (for a variety of reasons I won’t cover here). As it became more expensive, in terms of developers and long term risk, to invest in the iSeries, companies moved more and more to other technologies, such as Windows. This made the iSeries less attractive to others, and so the cycle repeats. Now, those companies, such as Widgets, Inc. that have a substantial investment in the iSeries, have hardware and software that is becoming increasingly difficult to maintain. Among their options are to maintain where they are and hope for the best, which is probably suicidal, or migrate to another platform, a path fraught with new bugs and lost opportunities, but probably one of the wisest options.

Now, let’s fast forward fifteen to twenty years in the future. While Windows is the dominant desktop operating system in 2004, while also holding a respectable position (in terms of numbers) in the server market, no one can know what 2019 will look like. With Microsoft under increasing pressure from rivals such as Linux and MacOS X (don’t laugh, more and more people are turning to Apple), that dominance can not be assumed to run ad infinitum (anyone remember the once proud and invincible big blue of the 60’s, 70’s and 80’s?). In fifteen years, we very well may find ourselves running systems predominantly based on Linux, or maybe even some other OS that currently exists only in some company’s R&D labs. Should that day come (and I feel it will. It’s just a matter of when), what are we to do with all of this .Net code?

Those on top of the .Net "community" will probably be quick to point out the Mono project or DotGNU, claiming that a cross platform .Net is on its way. To that, I would point to this article that talks about how Microsoft is patenting their Office XML file formats, so that they can restrict who and can do what with Office files. MS is patenting something that is standards-based as part of the business-as-normal process of blocking competition. Time will most likely show the heavy hammer of the Microsoft legal department falling on the efforts to the Mono and DotGNU groups as well. Even if that never happens, as long as Microsoft is not actively helping to port .Net to other platforms, these porting efforts will always lag behind the official product.

So where does that leave us? A whole bunch of nice, modular, object-oriented, garbage-collected code that runs on only one platform, but at least GUIs are easier to write. Every language has its problems. While there are things that are easier in .Net than Java, the inverse is also true. All that being said, though, if the decision to use .Net over Java is simply because UIs are easier, then the decision making process was extremely short-sighted. In fact, in my mind, it’s not really even a .Net vs. Java question. It’s a question of portability. Given the speed of modern languages and systems and what we’ve learned over the past 40+ years in this industry, there’s no reason why we should let any vendor tie us to their platform, whether that vendor is Microsoft, Sun, Apple, or Red Hat. With regards to .Net vs. Java, since their capabilities are so similar and run time benchmarks show that they run about as fast as each other, there must be something to tip the scales. If you ask me, IT managers should lean toward platform independence, and leave their enterprise room to maneuver should its vendor of choice start making decisions adverse to the enterprise’s goals and capabilities. If you’re not tied to your vendor’s platform, you can’t be strong armed into making decisions you don’t want to make. With .Net, though, you’re tying your own hands.