When I read the material on Yahoo! Blueprint, I was pretty pleased and shared the links with you in the last entry. However, I'd like to draw your attention to the first paragraph of their roadmap (emphasis is mine):
Declarative vs. Imperative
Much of Blueprint's philosophy and syntax comes from XForms. We opted for a full declarative language because it was the only way we could effectively run on the wide range of devices out there, some of which have no scripting at all. By using declarative syntax, we can encapsulate and hide the scripting specifics. In some cases, the code could run on the phone, in other case, such as XHTML, we can put the logic on our servers. It's the perfect way to deal with the various environments and their capabilities.
In a nutshell, this is the multimodality story of XForms.
I should clarify, though, that this is not saying that XForms has no imperative scripting of its own. The difference, though, is that the XForms script commands are data-centric, which means that they essentially declare what has to happen to the data in response to a particular event (like pressing a button to add a row to a purchase order). The meaning of each script command in XForms is tailored by the declarative constructs that bind to the data. For example, when you add a node of data containing the subtree of nodes needed to represent a purchase order item, the declarative bindings of XForms automatically create the UI controls and the line calculation formula needed to drive that new data. XForms processors, including Blueprint, are able to decide where these behavioral updates go depending on what devices are at play.
This issue of declarative constructs tailoring the meaning of imperative script commands is extremely powerful. Using the same one line of code to insert or delete a node, the rest of the application may respond by creating or destroying an arbitrary amount of user interface, including nested tables, as well as creating, destroying or updating any formulae that may be needed for the data being created or destroyed. The same one command that removes a row of a purchase order could also remove the entire list of delinquent payments for a customer who has just paid up.
In conclusion, it's not so much "declarative versus imperative". Rather, it's a matter of being much more effective with a hybrid model in which the imperative is data-centric and augmented by the declarative.
How much more effective, you ask? In The Mythical Man Month, Brookes states empirical results showing a relationship between complexity and code length of N1.5, where N is the number of lines of code. To put that in concrete terms, 10 times less code is not just 10 times easier to maintain, it's about 30 times easier. This is the kind of difference that turns years into months or months into days. For the services company this means lower RFP bids, which translates into winning more deals. And it means significantly lower TCO for the enterprise IT shop building that web-app in-house.