Published in TDAN.com July 2002
“We should find a way of describing what effect we want to achieve, rather than saying what sequence of steps the machine should take in order to achieve it.” Sounds like a statement
from an epistle on business rules, perhaps by C.J.Date, Ron Ross, or Barbara von Halle? No, this quote is from what some might consider an unlikely source–more on this later.
Procedural and Declarative: What’s the Real Difference?
The consensus within the business rules community, as C.J. Date explains in What Not How, is that the “what” in Date’s nomenclature–declarative rules –is somehow the opposite of the
“how” –“procedural” code. Let’s look very specifically at why “what” is different from “how”. Strictly speaking the terms procedural and declarative are not opposite
in meaning.
Procedural means following a series of steps in a regular definite order. A procedural specification is like a document; to make sense (to be clear) it must be read sequentially,
front-to-back, like a novel or a tape. It is a narrative!
Of course, due to the nature of our clock-driven computational platforms, arriving at a computer-executable set of instructions requires, at some point, the imposition of an appropriate order. But
as Date has pointed out, the ordering required to transform a declarative specification can, and should, be derived automatically from the functional dependencies of the data upon which the module
operates. This imposes a dependency of the rule set, and its subsequent corresponding procedural instructions, on the data upon which it operates. This is of course as it should be—define the
data first; then and only then can you specify the operations upon it.
The roots of “declarative” are the Latin words declarare, to make visible; and clarus, clear. Given this, it follows that specifications presented in a declarative manner should
be clearly visible. Rules are unordered assertions about data. A set of rules is comparable to a random-access medium–a CD or DVD, or a database. Regardless of where one initially
approaches the rule set, or in what direction one proceeds, the intent—the meaning—of the rule set remains clear. Compare this with Codd’s definition of a relation as, among
other things, an unordered set.
So Then What is Truly Declarative?
The characteristic of a truly declarative language that allows its statements to be unordered is that it is free from “side effects”. This means that no function in the language is able to make
changes in their environment, such that it can affect the execution of other functions. This actually means, for example, that a program written in a truly declarative language cannot change a
value of an internal variable to be referenced later in the program (“later” also assumes an order!). A very strict “rule” to follow.
A contemporary example of a declarative, side-effect-free language is XSL Transformations, or XSLT. Consensus is that XSLT, and declarative languages in general, are not easy to program in. Why?
Because we programmers, and former programmers, are used to writing narrative procedures–because that is the way we’ve been taught.
Third Normal Form Rule Sets?
The fundamental premise of normalization is that for each tuple (row) in a relation, the values of all its attributes are functionally dependent on the value of the primary key of the
relation—the set. Perhaps a similar concept can be applied to a “normalize” a set of rules—a rules module–which shares interdependencies with a common condition or value.
Barbara von Halle’s concept of a rule family, described in Business Rules Applied, points toward this direction.
The relational model, and specifically normalization, has been revolutionary in data management. But it certainly did not have an easy start. Business rules may likewise be off to an uneven start,
but they truly have the potential to revolutionize the specification of business requirements.
For business rules to achieve their full potential, “rules for rules”, as rigorous as those of normalization, are required for driving out anomalies and redundancy. Perhaps functional
dependency and side-effect elimination, among probably multiple other techniques, can start us down the road to making specifications truly declarative—and clearly visible.
Oh, yes, that quote at the beginning. It’s from the XSLT Programmer’s Reference, by Michael Kay.
