I always have to stifle a giggle when .NET experts expound upon the power of declarative syntax.  They sound like Merry and Pippin extolling the virtues of lembas.

I mean it. When I read this stuff on the page, I hear exactly that hushed and awed tone of voice.

The greatest thing since sliced waybread

Consider Bill McCarthy discussing how LINQ changes the way you will program in Visual Studio Magazine (Sept 2007):

As your code is translated in this manner, it becomes more declarative and you lose precise control over the when and how it works… you'll relinquish the control of "how" to them [the providers] and focus on specifying the "what".  The empowerment is from letting go, by letting providers choose what's best. 

Mr. McCarthy is exactly right. He's not just making a silk purse out of a sow's ear. Persuading programmers to relinquish control allows vendors to provide better tools, more easily.

Developer-tool vendors can easily create little design-time widgets to expose, decorate, and leverage declarative languages. The Visual Studio folks can't help but love how accessible declarative syntax is.

Data-provider suppliers, also, can't help but enjoy the freedom they get to fine-tune, and re-version, their engines as needed. Declarative syntax abstracts away any connection between the innards and the result, so users can't rely on the innards . Vendors can improve or completely re-vamp them at will.

Or not. 

But Mr. McCarthy has also put his finger on one reason why many programmers are unhappy with declarative languages. 

Most programmers enjoy, not to say crave, control. In fact many of them build their sense of their own worth as programmers, by assessing how finely their work controls the substances (data and interface) on which it operates.

If you think I am over-generalizing about programmer personality types, sure, yes, I may be. But please read Chapter 15 of Bruce Tognazzini's Tog on Interface before dismissing this idea out of hand.  It discusses Jungian archetypes and where, in an overall continuum of people, programmer-engineering personalities fit in.

It's a pretty old book, but it may change your life.  Come to think of it, read the whole book, if you haven't already.

MS folks tend to be pretty happy talking about XAML and other declarative dialects but I'm fairly sure that this is precisely because they are still, in some sense, in control of these languages, as the language designers.

The same MS folks are not as happy when discussing declarative languages they do not control and that don't easily mesh with their existing object constructs.

So what is XSLT, chopped liver?

Chief among these, from my admittedly-biased point of view, is XSLT, which is a superlative declarative syntax. It's far more powerful and far better integrated with data than the home-grown and unorthogonal "templates" used to do such things as decorate and databind ASP.Net controls from menus to details views to… well, all of them, actually. 

"XSLT is so counter-intuitive," I hear at MS.  And this is true, if you want to level the charges against XSLT that can easily be levelled against any declarative syntax.

You have to let go.  You must focus on what you want to happen — not how it happens, and absolutely not in what order things happen.

The last part is particularly significant.  Procedural programming often depends on being able to identify and exploit a sequence of events.  Even event-driven programming depends on being able to determine some factors about the environment in which the event occurs, unless the application is stateless with no exceptions at all.  Declarative languages often do not give you the ability to consult state or sequence.  You can't, for example, assign a value to a variable in XSLT and then re-assign it, because you'd be assuming you know in what order things are going to happen. The variable is what it is.

Mr. McCarthy's conclusion mentions the subtleties that "change the problem boundaries" and notes that the "You'd be right to feel a little uncertain: The subtleties are all too often the cause of unwanted side effects".  Here, too, he is 100% correct. But in declarative languages IMHO you should not seek to exploit side effects, even if you do happen to like the results when they happen.

If LINQ has an overabundance of side effects, let's hope LINQ X.0 is more refined.

Here, again, I'm probably biased because the XSLT standard makes a particular point of outlawing side effects, although you can supply a warning attribute when using extension functions that have side effects. You can read this interesting post from somebody who finds this counter-intuitive and not particularly useful.

Let's turn that slice of waybread over and spread SQL on it

People don't think about this very often, but SQL-SELECT is a declarative syntax, and a very expressive, beautiful one at that. 

SQL adherents tend to express this fact a little differently than XML folks. Instead of saying "SQL is declarative" they say "SQL is set-based, not row-based".  What they mean is the same thing, though: "don't focus on how something is going to happen or in what sequence; declare what you want to happen and let the engine decide how to do it." 

In SQL-Server and in Visual FoxPro you do have options allowing you to interrogate what the engine decides to do, and you also have hints you can supply to tweak the engine's decisions, but this is just enriching the fuel mixture.  You still shouldn't try to drive.

Lots of VB/ADO- and Xbase- trained folks fail to understand this, which is why they create temporary tables and iterate through them in their code, with not-very-performant results. Such code may look simpler and feel more intuitive than what a SQL-jockey would produce… But the engine can't do what it does best when you give it a row at a time to play with.

XSLT's data-nourishing results

I am going to keep trying to introduce SQL developers to XSLT, as I did recently in a walkthrough on how to change Reporting Services Excel output. Visual FoxPro people are probably sick of hearing me talk about it but I can't help it; just as in SQL Server Reporting Services, VFP output has the best chance of flexible results when it uses XML as an expressive intermediate format and adds transformations.

Yes, XSLT looks strange to both groups. But both groups have already had a very deep relationship, and a very positive experience, with one declarative syntax in SQL. 

What's more, XSLT was designed from the ground up to be data-friendly, by a standards group composed of data-committed individuals.  You'll find the same concepts of unique keys, foreign key references, index generation, and data relationships baked right into XSLT that you use when you manipulate data using more familiar tools.

If you think MS has a better idea using some other widgety thing, you should take a look at how Sandcastle, which produces Visual Studio documentation, works.  It's a scripted pipeline of XSLT transformations. And it's spanking, brand new. Internally, they know what's what.

You still have to let go.  But, c'mon, take a bite. One bite. 

One bite may not keep a traveller on his feet for a long day of labour but it is still much, much better than cram.