IanG on Tap

Chris Anderson points out that I wasn't being quite accurate in a recent blog. He takes me to task for implying that if something is all markup, then there's no code. This was in reference to Joe Marini's pure XAML RSSreader. Chris, I apologise for selling your technology short! It's true that I was too focused on the 'wow, this makes it easy' without really paying enough attention to why it is easy, and glossed over that with little more than Oo! Declarative!

So I mostly agree with Chris's critique of what I wrote earlier. But not entirely. So I'll go into a little more detail on what I really think this time, rather than just jumping up and down with excitement about how this is going to increase my productivity...

Declarative Programming: Enabling or Enabled?

I completely agree with Chris that a declarative model isn't "magic powder." It is obviously no intrinsic guarantee of simplicity. For example, you could, I suppose, use XAML with the CodeDOM, if you were looking for a particularly non-simple way to code. And more realistically, Chris points out that XSLT, which supports declarative XML-based programming, can look pretty freakish even for some tasks which are simple in a traditional imperative language.

I emphasized the wrong axis in my previous post. It's not the declarative vs. imperative distinction, or markup vs. [other] code, or even behaviour vs. structure that's the key to the productivity benefits. (These are of course important features, they're just not enough on their own.) The crucial thing I failed to mention is that this simplicity is enabled by the expressiveness of the underlying abstractions.

Here's where I start to disagree slightly with Chris. (Either that, or here is where I misunderstood what Chris meant.) In his third paragraph, he seems to single out XAML as the thing offering the key productivity boosts. I wouldn't rank that as the most important part - I would have put it a close second.

Consider the demonstrations showing XAML building stuff like Hello World. These are slightly initeresting for their 'Oh, that's cool' factor, and slightly more interesting in their educational 'Oh, that's what XAML is doing' capacity. But I think what's particularly interesting is the relative inelegance of these examples compared to some of the Avalon examples. XAML's potential is best illustrated with a framework designed to make use of it. As Matthew Adams succinctly put it in reply to my previous blog (I really must get around to writing a comments feature so people don't have to email me these comments...):

"I think the really smart thing that Avalon provides here (in fact, the fundamental thing that delivers the productivity improvements) is the universality and symmetry of the elements in the tree. Defects notwithstanding, you can compose pretty much anything from pretty much anything else"

Choose Your Weapon

Of course Avalon's not just about being used from XAML. Again, I'm in agreement with Chris here - I don't think there's any need to pursue a 'pure' declarative approach. As it happens, I think Joe's RSS reader does manage to achieve that, but I was only trying to draw attention to how much power this style offers, rather than advocating it as the way that all applications should be written. Indeed, I think its support for a mixture of idioms is one of its key strengths.

If you go outside the bounds of some declarative languages' intrinsic capabilities, life tends to get hard. I've done a lot of XSLT work, and it's great right up until you come up against something that's not a natural fit for XSLT's intrinsic capabilities, at which point you end up having to write a lot of unnatural-looking goop.

XAML offers two ways around this. First, because it creates objects, you can always go and write normal imperative code to go and talk to the objects you set up with your XAML, if that looks like the easiest way of getting the job done. You can pick the most appropriate technique, rather than having to code your way backwards through a corkscrew like you sometimes have to in XSLT. You can use markup where it suits you, and you can use imperative code where it suits you.

Second, XAML's functionality is not closed. When you do come across something you want to do that isn't built into the system, you have the option to extend the set of abstractions - XAML is happy to create any .NET type, so there's nothing stopping you creating your own custom element types to build the abstractions you need.

So the aspect I liked so much about the XAML RSS reader, and which I ineptly summed up as 'no code', might better be described as 'no goop'. (OK, so that's hardly any more ept than before as far as elegant use of the language goes, but I'm not aware of an existing name for this axis; I considered calling it 'Foo vs Bar' in this blog's title. Although Steven Clarke may well have a name and precise definition for it. Or possibly several. Perhaps his 'Role Expressiveness' dimension might be closest to what I'm thinking about.) What I want from any software platform is to be able to write source that expresses what I'm trying to do as succinctly and directly as possible, without needing goop to work around the limitations. The combination of the declarative model and a straightfoward markup language for expressing it go on to improve the succinctness, but without a powerful underlying model to support it, markup on its own is not necessarily all that great.

So I stand by my original position that this demo "is a great illustration of how much you can get done declaratively," I'd just like to clarify it's not the declarative model itself that enables this ease of use. I think that it's the expressiveness of the underlying object model that makes it possible to get so much done in markup.

Choose Your Terminology

On Chris's statement that XAML is 'clearly in the code space,' I'm not sure if I completely agree here. I find this hard to reconcile with his other statement that HTML is 'much more document than code'. Doesn't every element in an HTML file correspond to an object in the DOM?

I've not had enough time to do much XAML yet, so maybe I'll change my mind in due course, but right now, XAML feels more like HTML to me than it does like XSLT. XSLT feels distinctly other. When I write HTML or XAML, it feels like I'm building up some kind of tree-like data structure that represents what I will see on screen. Writing XSLT feels more like I'm writing Prolog in XML. Of course all three of them involve creating a hierarchical structure using markup simply because they're all XML based, but for me, the big difference is that with HTML and XAML I'm defining the structure of my UI, but with XSLT I'm defining a bunch of rules that tell the XSLT engine what to do.

Another way of putting it is that HTML and XAML mostly define what is to be created, while XSLT mostly defines what is to be done. They are all still declarative - specifying what, not how - but the kinds of things being specified seem different. (This is what I meant earlier when I mentioned in passing the structure vs. behaviour distinction.) Of course this isn't a pure distinction - there are behavioural aspects which can be specified in XAML too, particularly when viewed at the coarse-grained scale: when I put, say, a list control of some kind on a UI, there's a whole host of behaviour I've asked for right there. But when it comes to specifying behaviour in the details rather than in aggregate, I'm expecting to put more of that in the codebehind than in the markup.

So as a reasonably experienced XSLT programmer, I clearly have to agree with Chris's contention that you can write code in angle bracketed form, but the fact remains that to me, XAML still feels more like markup than code.

Of course, this invites the response "But it's all markup - what do you think the 'ML' in XML stands for?" And this makes me wonder if the main problem here is my use of terminology. To me 'markup' is the source that defines the structure of something you'll be looking at. And because the UI technologies I've worked with over the last few years have a very close correspondance between the objects you create and the things you can see, I tend to regard defining the structure of a UI, and building up sets of UI objects as being pretty much the same thing. So that's why I think of XAML as a form of markup. (Also, most of the non-UI XML work I've done uses XML as a way of passing structured data around, which reinforces this particular world view.)

Of course, it's also perfectly reasonable to think of markup as being a way of annotating text. For some markup languages that's the only sane way of looking at them. For HTML and XML it's a grey area because both have standard DOMs that represent the documents in object form. But for something like nroff, a data-structure-centric view doesn't make a lot of sense. And for a lot of HTML, the 'annotated text' model is often more appropriate. So given this definition, then I would agree that XAML isn't markup - I'm definitely doing more than marking up some text.

So perhaps there are three categories your source might fall into:

1. Annotated text
2. Structured data
3. Behavioural instructions

nroff is in category 1. Both HTML and XAML can be in either category 1 or 2, depending on how you use them. XSLT is firmly in category 3. I think this categorisation is independent of the declarative vs. imperative distinction. For example, C# is in category 3 most of the time, but the InitializeComponent method generated by VS.NET seems like an imperative version of category 2.

Joe's RSS reader looks to me to be mainly in category 2, and entirely declarative. And this is a testament to how well XAML and Avalon enable a declarative style, rather than being an intrinsic property of declarative styles per se.