|
INTEGRATION WATCH:
The Unfaithful Spouse
By Andrew Binstock
 October 15, 2004 — Recently, I completed a complex, client-facing application that had unusual user interface requirements and it made heavy use of XML, network access, and various forms of encryption on the back end. More than in previous projects, as I negotiated these various programming domains I had the sensation that I was using the wrong programming language: with C++, I was always working at too low a level. It was akin to mowing my lawn with a pair of scissors. The choice, alas, was unalterable because the product could not impose on users the requirement of installing a runtime framework such as .NET or the Java runtime.
The two things I missed the most were garbage collection and a comprehensive, well-implemented library of APIs. Having spent so much time in the trenches on this project, I have decided that all future work must allow the use of a runtime framework, so that I can avail myself of those two important features. I just can’t afford the time lost anymore.
As luck would have it, on my next project—another client-facing app—I can use either C# or Java. A few months ago, I would have chosen C#. I like the language. I like being able to go to ASP.NET when necessary. I really, really like Visual Studio .NET, and I think the extensive APIs are comprehensive and well-designed. I’ve used C# and Java and I have no religious feelings about either, and the biggest knock on .NET—its lack of portability—has been removed by the release of Mono. So, what’s not to like about C#? Microsoft’s lack of fidelity to published programming APIs.
This project is likely to serve as a core component to a larger software package. As such, it will need to be tweaked and maintained in the years to come. As I look out five to 10 years, my enthusiasm for C# begins to wane.
Let’s look at this a bit. Anyone who was coding for PCs during the mid-1990s recalls the painful conversion from Win16 to a sequence of difficult-to-distinguish Win32 variants: Win32s, Win32g, and finally, Win32. We then had MFC, which was unavoidable if you wanted to remain at a reasonable level of abstraction. Then last year, we were all force-migrated to C# and .NET (VB programmers have their own painful version of this story). I liked the language and hoped that with Redmond’s commitment to this platform as its future, my investment in learning the APIs would carry me for 10 years, maybe more.
But Microsoft forked this hope with the announcement of WinFX, a new API to be released in 2006 that will replace Win32 and modify the .NET APIs. This announcement means I must consider the distinct possibility that code I write today will be too old to maintain in 10 years. Not that it won’t run, but that necessary changes will not be possible because the dev tools will no longer exist and the code base won’t be portable to the then-current Windows APIs. My only option will be to rewrite or port the application some time during that timeframe or, more likely, to abandon the software because it can’t easily be upgraded. Yech! Who has time for that kind of nonsense?
Java by comparison suffers from no such problem. The community process that’s so widely blamed as an obstacle to innovation prohibits the sudden rewriting of thousands of core programming interfaces. While some early APIs have been deprecated over the years, this superannuation happens slowly and with deliberation. The core APIs of version 1.1 are much in use today. And code written for the AWT still works well today. Notice that Swing did not banish AWT, it extended it in new ways.
When I code in Java, I have every reason to believe that in 10 years someone can look at my code, understand it, and modify it to suit new unanticipated demands. Java feels like a reliable and faithful partner, Microsoft like someone who wants you to get engaged but will not pledge fidelity.
To Microsoft apologists who feel that the radical change to APIs is a normal event in the progress of all operating systems, I would suggest they look at Linux. It has undergone more growth and more internal change than any other operating system during the last decade, and yet it has steadfastly (and successfully) stuck with the SVR4 UNIX interfaces. Code from early Linux will generally run with little if any changes required.
The value of steadfastness is greater than this question of code longevity. It also saves me from having to relearn things periodically. I don’t mind learning new APIs to exploit new functionality (such as JXTA, for example) but I do resent being forced to learn new concepts so as to do nothing more than I was doing before—just with a different API. As a result, I expect that my future platform choices will increasingly be toward Java and for exactly this reason.
Andrew Binstock is the principal analyst at Pacific Data Works LLC.
Andrew Binstock is the principal analyst at Pacific Data Works LLC
|
|
Advertisement
Click here for a complete listing of Integration Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|