Did you notice that the cost of Y2K remediation failed to crush our economy?
Why anyone thought it would is mystifying. Two years ago I predicted the economic non-impact of Y2K, because its major economic impact was a transfer of wealth … mostly from corporate coffers to individual middle-class computer programmers … not the elimination of wealth from our economy.
The absence of a Y2K-like crisis, in contrast, may cause real problems. Why? Money moving from the wealthy into the middle class is healthy, not detrimental, to the economy. If IT spending slows down, less of that will happen. In the bargain the IT labor shortage will ease (and programmer unemployment will rise) as corporations, overwhelmed with their usual sentimentality, wave goodbye to the hardworking employees who got them through.
We’ll see if it happens that way this year.
Since we’re updating past predictions, let’s talk about Java. Microsoft tried to “help” me on my prediction that proprietary extensions would diminish Java’s “write once/run anywhere” promise by adding Windows-specific features to its version, but the courts sided with Sun. So here’s a replacement prediction: Despite Sun’s current recalcitrance, within two years, its partners will no longer accept its hegemony. Either Sun will turn Java over to a standards body or its partners will de-emphasize Java in their strategies.
It will matter less and less, though, because my other prediction about Java … that it will become just another programming language, disappointing its most vocal advocates … is on track. Both Lotus and Corel have abandoned their attempts to market Java-based office suites. No vendors have released successful large, Java-based business applications, either. The best we’ve seen are systems that use Java in the mid-tier and to enhance browser-based functionality in the user interface.
Updated prediction: Java will find a niche as the mid-tier language of choice in n-tier OO/client/server development projects, although its performance deficiencies compared to compiled languages will continue to constrain its value.
Java will continue to be useful in extending browser-based interfaces. Here’s a long-shot: unexpected competition from Macromedia, which has been adding functionality to Flash and Shockwave and recognizes (in 2001?) that adding forms with database and transaction connectivity is a logical addition to its feature set.
Whatever else, happens, Java will not become what COBOL once was — the dominant tool for developing business applications in mainstream IS.
If Java will be disappointing except in the mid-tier, how about its companion mid-tier technology, XML?
XML, which is basically a pragmatic version of SGML, will increase in importance. It didn’t take a lot of courage to predict XML’s success last February so I’m not claiming credit for prognostication. Most technologies that receive as much hype as XML end up disappointing their promoters, though. XML won’t.
Except for this: Among XML’s advocates are naifs who expect it to be a sort of technological Esperanto, except that people will actually use XML. In other words, there are those who expect XML to be a universal language where everyone who speaks it can communicate with everyone else who speaks it.
It isn’t. Language requires syntax, vocabulary, and semantics. XML only defines syntax. For each context in which XML holds promise, market leaders will define specialized XML vocabularies. These efforts will be most successful in creating a replacement to both HTML and proprietary file formats, merging these two art forms into one, standard way of representing documents.
While XML also will succeed as the language of choice for defining metadata, the nature of its success will come as a disappointment for many eBusiness evangelists. The hard work of mapping internal data structures to each specialized industry or supply-chain XML vocabulary will be subject to the same semantic difficulties that have plagued Electronic Data Interchange since its early EDIFACT/ANSI X.10 days: Even when two companies use identical tags to label data fields, the meaning each assigns to a tag may be subtly different, simply because the two companies think about things differently.
That’s to be expected. Human knowledge is messy. Its representation … in XML, English, or Urdu … will, of necessity, be messy, too.