Hi Folks,
Ken, thank you for your response. I appreciate it.
Your message helped clarify an issue that, frankly, has eluded me for a long
time.
Up to now, I've been framing the question as:
Which is a better way to design a system: declarative or imperative?
But your message suggests that this may not be the right question.
The real question seems to be something closer to this:
How do you structure a system so that shared behavior is centralized, while
variation is handled cleanly and locally?
In your publishing example, the core XSLT defines the default behavior, and
each client provides only a thin "outer layer" that overrides what needs to
change. The core does not need to know how it is being used, and each client
can specialize behavior without affecting others.
That is a very different model from what I typically see in imperative
systems, where variation often leads to conditionals, branching logic, and
duplication scattered throughout the code.
What strikes me is that this "onion skin" layering makes the declarative
nature of XSLT much more visible. The benefit is not in a head-to-head
comparison on a single task, but in how the system evolves as requirements
diverge.
In that light, I can see why a small example might fail to make the case,
while a layered, multi-client system makes the advantage much clearer.
This is a very helpful perspective--thank you.
Best,
Roger