I’ve always blended the geeky, command-line-driven Unix style with the mom-friendly point-and-click Windows approach. To borrow a Microsoft Corp. slogan, the two approaches are “better together.” Each has strengths that complement weaknesses in the other. However, we’ve yet to achieve real synergy.
Innumerable essays have compared the two cultures. The most recent of these, written by software developer and commentator Joel Spolsky, nails the essential difference. Unix programs are written to communicate with other programs first, then optionally with people. Windows programs, on the other hand, are written to communicate with people first, then with other programs.
Mac OS X fans will tell you that it delivers the ideal synthesis of the two cultures — Mac comfort and charm up on deck, Unix flexibility and power down in the engine room. But the upstairs/downstairs metaphor betrays the real deal. OS X only brings the two cultures under one roof, it doesn’t really merge them.
What would a true synthesis look like? Regular readers of this column can already guess my answer. When we use XML for program-to-program communication and also for program-to-person communication, we will finally be able to combine strengths with strengths.
On the Unix front, we’re not there yet. Unix’s way of composing systems by piping textual data between components was, and is, a stunningly good idea. But XML is changing the nature of textual data. Now programs can absorb it using a single standard parser rather than the dozens of purpose-built ones that still clutter every Linux distribution. And programs can transform and query the data because their elements aren’t just identified by delimiters and positional offsets. Instead, the elements have names and verifiable structure.
So why isn’t XML fundamental to Unix culture? The fact is that Unix-like systems depend on dozens of purpose-built parsers, on the oddball formats associated with them, and most critically on generations of finger-knowledge tied to those formats. It would be risky and disruptive to make wholesale changes, and the benefits — although real — aren’t sufficiently compelling. Of course XML still isn’t fundamental to Windows culture either. The GUI that Windows appropriated and made dominant in the early 1990s proved, a few years later, to be ill-adapted to the Web. The HTML browser showed us that a GUI driven by declarative markup was good enough for many purposes. But HTML isn’t XML. Its expressive power markup leaves a lot to be desired. Hence the plan to drive Longhorn’s GUI using XAML (Extensible Application Markup Language).
It’s clear that that the future of the Unix-style pipeline lies with Web services. When the XML messages flowing through that pipeline are also XML documents that users interact with directly, we’ll really start to cook with gas. But a GUI doesn’t just present documents, it also enables us to interact with them. From Mozilla’s XUL (XML User Interface Language) to Macromedia’s Flex to Microsoft’s XAML, we’re trending toward XML dialects that define those interactions.
Where this might lead is not so clear, but the recently published WSRP (Web Services for Remote Portals) specification may provide a clue. WSRP, as do the Java portal systems it abstracts, delivers markup fragments that are nominally HTML, but could potentially be XUL, Flex, or XAML. It’s scary to think about combinations of these, so I’m praying for convergence. But I like the trend. XML messages in the pipeline, XML documents carrying data to users, XML definitions of application behavior. If we’re going to blend the two cultures, this is the right set of ingredients.
