Novel, yes; widespread, no

That's right, kids, November is over and while my novel isn't "done," it did indeed pass 50000 words. I have a tiny bit of work left to completely wrap up the story, and a little bit more tweaking before it's up to my usual questionable quality standards (as opposed to its current "unquestionable" quality). That should only take a few more days.

And after that, you, yes, you, the one and only, will still not have access to read it, because I'm not currently planning to post it publicly anywhere, lest Google reveal to all the world that I'm an idiot. But I'd probably send you a private copy if you asked.

Old news, new acronyms: REST vs. SOAP

I've been seeing news in random places around the web lately announcing the official death of Web Services and SOAP in favour of REST, or was it XML Schemas in favour of RelaxNG, or whatever bad things the people in question don't like in favour of whatever good things the people in question do like. You can find many of these links by following links from Tim Bray's Ongoing.

And then comes the inevitable reply, They Can't Hear You, explaining that these so-called "deaths" are rather overstated, because all of the supposedly "bad" technologies are still very much in use in big companies everywhere, and moreover, most people in those companies haven't even heard of the so-called "good" technologies.

Now, of course I'm always totally in favour of a good flamewar, but if the flamewar is good enough, then I prefer to confuse the issue rather than resolving it. Thus, I bring you my considered opinion:

Yes, it seems those bad things really are dead. But they're not. Except where they are.

You see, declaring SOAP dead in favour of REST is equivalent to declaring Windows dead in favour of Unix. No, no, not "just as stupid." I mean equivalent. If one was true, the other would probably also be true. And you may have noticed that Unix has totally prevailed. But it hasn't. Except in the places where it has.

A while ago at NITI I did a presentation about functionality vs. elegance. Basically, I argued that people often treat them as a single continuum, sacrificing features for beauty or vice versa according to their priorities. But really they're two independent dimensions, and a small few things are functional and elegant.

In my example at the time, I showed how Windows isn't elegant (well duh) but it is highly functional; you can make it do anything. Unix, on the other hand, was an amazing achievement in its heyday because it was highly functional and highly elegant. Because this was originally true, people experience the beauty of Unix and then tend to believe that "the Unix way" is the best way to solve all their problems.

Unfortunately, original Unix was designed for processing text on a command line. Its elegance came from clever, well-executed simplifications like the unified filesystem, devices-as-files, pipelines, and everything-as-text. Unfortunately, none of those things have anything to do with graphical user interfaces. X11 is anything but elegant, and none of the various Unix widget toolkits are earth-shatteringly great like Unix was. Furthermore, trying to map elegant command-line stuff into GUIs has been a consistent, horrible failure; compare a Windows-based IDE debugger to any GUI wrapper on top of gdb, and just try to tell me I'm wrong.

To make something both highly functional and highly elegant, you need what we call a simplifying assumption. In the command-line world, the credit typically goes to the invention of Unix pipes, which let you easily link small tools together to accomplish a big job. Windows has no such magic (well it does, but they forgot to support it in the shell), and so it predictably sucks at text processing. But Unix has no simplifying assumption in its GUI. So they have to trade off between functionality and elegance. In typical Unix fashion, this means there are a zillion half-baked alternatives, each at different points along the tradeoff continuum.

But there are places where Unix's traditional elegance is still a win, and that happens to be the world of Internet servers. The web works because it mostly just paraphrases Unix's cleverness. It has a unified filesystem (er, URI space), devices-as-files (er, CGI scripts generating content), and everything-as-text (html). Sadly, its UI mostly sucks, except for the AJAX stuff where we basically hack the hell out of Javascript and CSS to mangle it into a decent UI, at the cost of almost all the operational elegance. That's because what's missing from the web model (and the Unix GUI, for that matter) is an analogue for Unix's pipelines - I can't easily connect one little thing to another little thing to generate a high-quality big thing.

The fancy modern name for that is a component system. Unix pipelines are one kind of component system, although people who talk about Component Systems as if they had Capital Letters would probably gasp at my saying so. That's because those people design the second kind of component system: things like COM. You know: the way Windows does it.

So here's the thing. In the world of the web, there are two competing ideas for component systems: REST and SOAP. And these correspond almost exactly to Unix and Windows, or in other words, pipelines and COM. Pipelines contain squishy (nowadays Web 2.0 people would say "mashable") text in which the format is flexible and implicit and probably being parsed only 99% correctly. That sounds to me exactly like REST and microformats and RSS and friends.

Meanwhile, there's SOAP and SOA and WS-Whatever and XML Schemas. They're just like COM: useless unless your syntax and semantics are exactly right, semi-easily checkable for valid syntax, and purportedly self-describing in an essentially useless way (except for syntax checking purposes). Self-describing or not, Google will never be able to index your SOAP service without a special plugin, just like Google Desktop can't index any of your binary document formats without special COM plugins, one per format.

Phew. Okay, so that was the background information. Here's my point: yes, the whole Internet runs on Unix philosophy. But businesses sure don't. The big problem comes up in my description of pipelines up above: they only parse about 99% correctly, which is fine for your idiotic comments about YouTube videos, but pretty nasty when you mangle critical business data. And when the business dudes get involved, they'd rather do anything than mangle their critical business data. You hear me? Anything!

If it keeps the data from getting mangled, they'd happily sacrifice searchability. Or developer hours. Or the ability to use off-the-shelf software. Or millions of dollars in licensing fees (because at least they'll accurately know how many millions).

Pay attention, because that attitude is exactly why Windows is so strong, why the vast majority of developers prefer to develop on Windows, and why the vast majority of users prefer to use Windows. It may be gross, and adding new features or libraries may be a lot like stabbing yourself repeatedly with a fork (which, tragically, is not itself included in Win32), but Windows works consistently. So does SOAP. But not Unix or microformats or REST.

It would be awesome if someone could find a way to satisfy both camps (the Internet people and the Enterprise people) at once. Then maybe one or the other set of technologies could finally die. But I'm not counting on it. Until then, one or the other technology is effectively dead, but which one it is depends who you are.