I've made this Community Wiki because some may think it's open to debate and others might think it's a question of using words to mean what they really mean (in other words, it's a matter of opinion whether it's a matter of opinion).
There's a general question on SO about declarative programming, which has some great answers.
But I'm a bit thrown by this blog post from a Microsoft evangelist.
One advantage of declarative programming is that you can indicate what you would like to do, but not how to do it.
So far, so good - that exactly agrees with the accepted answer on the SO question, in fact.
But then check out the part about "Service implementation",
You can just look at a few dozen lines of xaml code and be able to determine how the WCF Service is configured and how the corresponding workflow is defined.
Having looked at some examples, let me briefly answer that by saying "No, I can't". But rather than flippantly dismissing this stuff, let's look at the docs.
It's taken a while but finally reality has caught up with satire... but that's not the point - of course they aren't seriously suggesting doing this to expose something trivial like addition. Nor am I complaining about the ridiculous verbosity, and the strange idea that anyone would ever write something like that by hand - it looks more like the output of a compiler than a human-readable language.
The puzzle for me is that this is claimed to be "declarative". And yet the core of it is an assignment statement.
Declarative services are defined declaratively in XAML and provide another layer of abstraction. Basically, you create a model of the service by defining what you want the service to do rather than how to do it. The entire service can be defined declaratively, including the implementation of the operations.
So if we say declarative or declaratively three times, that makes it declarative. Gotcha. And if we say the magic phrase "what you want to do rather than how to do it" then we can neglect to notice that in the very next sentence, we are going to specify "implementation of the operations" after all, and so we are going to say precisely how to do it.
The example in that page is:
<wma:Sequence>
<wma:WriteLine Text ='[String.Concat(String.Concat(String.Concat(String.Concat("Add(", CType(op1, Object)), ","), CType(op2, Object)), ") called")]' />
<wma:Assign x:TypeArguments="xs:Int32" To="[result1]" Value="[op1 + op2]" />
</wma:Sequence>
Which is to say, the whole thing (including a ton of junk I've cut out from the WF example) is precisely equivalent to:
void Add(int op1, int op2, out int result1)
{
Console.WriteLine("Add(" + op1 + ", " + op2 + ") called");
result1 = op1 + op2;
}
So - a block of statements, to be executed in the order they appear, and having side effects. There are of course workflow activity elements for looping (and you can write your own activities if WF doesn't already have your favourite imperative statement). Apparently, "rewriting your code in an unreadable format" is the same thing as "adding a layer of abstraction".
To reiterate, it's not the insane unreadable verbosity I'm complaining about - it's the fact that it is clearly Turing-complete imperative programming happening in the service implementation, so what's the point? Before you know it, we'll be stepping through our workflows in the debugger, trying to figure out which assignment statement mutated which value, or why the loop keeps going round forever.
(The irony is that in the C# version, it's a little more declarative, because we haven't specified how the pieces of string should be concatenated, thus allowing the compiler to generate fewer calls to the Concat method.)
So does writing something in XML make it declarative (as well as less readable)?
