Dr. Dobb's Journal August 2000
A little book that recently came across the transom got me to thinking about some issues that I hadn't explored in such depth in a long time. I found myself reexamining logic programming, the declarative paradigm, and the value of studying obscure, old programming languages. Like Prolog. To the five readers who took offense at that, yes I realize that Prolog isn't obsolete. It only became an ISO Standard in 1995, and it is in wide use throughout the world in a wide variety of applications and on a wide variety of platforms. The word "variety" is apt here; I've been playing around with a BeOS implementation of Prolog that began its life as a Newton program. But that's not why I called Prolog obscure; it's because I'm betting that a majority of Dr. Dobb's readers have neither written a Prolog program nor expect ever to write one.
The book is available, accessible, and by a well-known author. It's What Not How: The Business Rules Approach to Application Development, by C.J. Date (Addison-Wesley, 2000; ISBN 0-201-70850-7). This book is probably not one we'd put high on the list of book-review candidates here at Dr. Dobb's (and this column will not be a review of it). The first half of the book is a manager's guide, aimed at people with little or no programming experience, and the second half mostly reviews material that anyone who has done database programming already knows, although it covers this material from a particular perspective to make a particular, not uninteresting, point.
Also not in the book's favor, from the Dobbsian perspective: It's only 130 pages long, is written in a chatty style because it apparently began its life as a script for a live presentation, and it was commissioned by a company that has an interest in promoting business rules -- something that Date does enthusiastically in the book. Also, despite the subtitle, it's not even really about application development.
Nevertheless, I got a lot out of reading the book. Date's credentials in database programming are solid. His An Introduction to Database Systems is a standard text in the field and has sold over half a million copies. He was involved in technical planning for IBM's SQL and DB2 products and has been one of the chief promoters and clarifiers of the relational model for database programming. He is also passionate about the subject of business rules, and the fact that he wrote the book under contract to a business rules company is probably not important, since he doesn't promote its -- or anyone's -- products in the book and would doubtless be promoting the use of business rules regardless. As I followed the threads of Date's What Not How theme out of his book and onto the classic languages shelf here at Stately Swaine Manor, and finally back to the book with some fresh perspective on the issues discussed, I found myself rethinking an old affection for paradigmatic purity.
Business rules make up the recalcitrant "third component" of business software. The other two are the presentation and database components, for which there are many tools in existence to automate various aspects of the development job. The third component, business rules, encompasses the knowledge specific to the particular business, and has traditionally not had many tools dedicated to automating its tasks. Some business rules might be:
pay = salary + commission + bonus
commission + bonus < $5000
total_owed <= credit_limit
if quantity_on_hand - quantity_ordered < reorder_level then reorder
customers whose accounts are overdue must be displayed in red
an employee has one manager
never_married -> widowed is not a valid transition
legal supplier numbers are of the form Snnnn
if the portfolio_value of Account > 25000 or at least 50 Trades of
Account satisfy Commission > 29.95 then the enterprise_value of Customer
is "GOLD"
the items covered by a lease can change during the term of the lease so
long as the monthly lease payment does not decrease
This is a very mixed bag. Some of these rules indicate an action to be taken (reorder), while others express constraints or look like instructions to programmers or database designers. The question motivating Date's book is this: "How do we automate the processing of such a messy collection of admonitions?"
Having characterized the content of this component in the way that he has, Date has pretty much answered his own question. If business rules are expert knowledge, the natural conclusion is that we need some sort of expert system to embody and process that knowledge, along the lines of expert systems in medical diagnosis and other fields. That means declarative programming, which differs from procedural programming precisely in its emphasis on specifying what to do rather than how to do it, hence the book's title.
One phrase that nicely communicates the promise of the declarative paradigm is "executable specs." It has a nice ring to it, doesn't it? The task of developing software would become a whole lot easier if you were finished when you had written the specs.
Business rules are specs. And business rules are declarative -- mostly. A few business rules are phrased procedurally:
if quantity_on_hand - quantity_ordered < reorder_level then reorder
but most impose some constraint:
total_owed <= credit_limit
or define something:
pay = salary + commission + bonus
or assert something:
legal supplier numbers are of the form Snnnn
all of which are declarative acts (even if one of them looks like an assignment statement).
Date's book is about making this particular kind of spec executable. To make business rules executable, you need an appropriate language for interpreting and executing these rules, and Date summarily dismisses Java, C++, and other object-oriented languages for this purpose, although there are certainly Java- or C++-friendly bizrule tools available. More than just a language, you need an engine to interpret these constraints and apply them where relevant. An expert system, in effect. Add that it needs to be efficient, with compiled rather than interpreted rules, and sophisticated optimization.
Although I do database development for my partner's business (an organic farm and restaurant), I hadn't thought about business rules as anything but part of the documentation on how the database files are constructed and used. Unsophisticated, I know.
When Date got me thinking about the idea of automating these rules, I immediately flashed back to my study of Prolog.
Reading Date sent me back to the dustier shelves and to books I hadn't read in years. Is there value in studying old programming languages? I've always thought so, or rather, I've thought that the value in studying old languages was directly related to the purity of the conceptual underpinnings of the language.
I went to college in an era when history was being denigrated. "What's the relevance?" The answer was usually, none.
The world seemed to be changing rapidly then, and it seemed appropriate to ask what relevance the past had for our present and future. In retrospect, it seems sad that we of that generation failed to see the value in studying the past. Not just my generation, of course. The sense that the world is changing rapidly hasn't abated, and I don't see any renaissance of interest in history.
So in pitching the importance of studying old programming languages, I come from a historically challenged perspective and I suspect I speak to a historically challenged audience. But programming is about process, not content, and past languages can be mined for good techniques, practices, and insights. The clearer those insights are, the less they are embedded in irrelevant implementation details, the more likely they are to reward study.
If you buy that, you'll agree that studying McCarthy's original Lisp is an appropriate way to get back to basics and clear your mind of irrelevant details in thinking about functional programming. Another mental cleansing agent might be Chuck Moore's original Forth. If you don't buy that argument, you'll probably point out that some ideas that once defined whole languages or schools of thought in programming or paradigms have now become mere tools in the programmer's bag of intellectual tricks. Snobol, historically, seemed to offer a different paradigm of programming. But standards of originality evolve, and today I suspect we would see the historical Snobol as a one-trick pony, doing little more than string processing via a syntactic minimalism that reduces everything to one or another variant of a single test/branch/replace statement. The kind of thing that computer science students invent when they create their own UNIX batch programs. I guess my response would be that not all paradigms are equal, and that some are so rich and powerful that they are worthy of being examined in the purity of their original implementations. If so, the declarative programming paradigm as implemented in Prolog has to be one of these.
Although some of my Prolog books are a little dusty, Prolog is still alive and vital.
Prolog was invented at the University of Marseilles by Alain Colmerauer in the early 1970s. It got a big boost in 1981 with the publication of Programming in Prolog by W.F. Clocksin and C.S. Mellish (original edition Springer-Verlag, 1981). Other inflection points in the curve of its adoption occurred when the Japanese adopted it for their massive Fifth Generation AI project in 1982, and in 1984 when Borland came out with its low-cost, efficient Turbo Prolog for PCs. Prolog became the official language for much work in artificial intelligence during this time. It took another decade before Prolog became an ISO Standard, but that finally happened, too, in 1995.
While artificial intelligence was earning a reputation for not delivering on the hype, one branch of AI -- expert systems -- was quietly turning out useful products. Expert systems, generally written in Prolog, were of actual value in many fields, and led directly to systems for processing business rules. Last year, IBM showed off a prototype of CommonRules, a Java library for declarative logic programs for processing rules. CommonRules also embraces an XML interlingua called "Business Rules Markup Language" (BRML). (CommonRules grew out of an earlier project whose buzz phrase was "intelligent agents" and whose implementation language was C++; now it's "business rules" and Java plus XML. Who says IBM is stodgy and uncool?)
Every Prolog system (program? database?) is, basically, a resolution theorem prover for Horn clauses. There are two terms in that sentence that require definition.
"Resolution" is a rule of inference discovered by J. Allen Robinson in the 1960s that can be used to automate deductive reasoning. Resolution operates on clauses, which are a calculationally convenient way of representing propositions in the predicate calculus. Given two clauses related appropriately to one another, resolution will automatically generate a third clause that is the logical consequence of the first two. A Horn clause is just a clause with at most one unnegated literal, such as:
person(adam)
person(eve)
person(X) OR NOT mother(X , Y) OR NOT person(X)
(Each of these has exactly one unnegated literal.) If you use the Prolog notation of :- for "is implied by," and the Prolog convention of ending each clause with a period (.), you can rewrite these as:
person(adam) .
person(eve) .
person(X) :- mother(X , Y) , person(Y) .
The first two are facts, the third is a rule. Resolution is both correct and refutation complete. This means that a system built on the resolution principle, when repeatedly applied to a set of mutually inconsistent clauses, will derive the empty clause and only the empty clause. The empty clause represents falsity in such systems. This in turn means you can use resolution to prove any clause that it is possible to derive from a given set of clauses. You do this simply by showing the inconsistency of that set of clauses with the negation of the target clause. For example, given the aforementioned set of clauses and the goal clause person(adam), you would negate it and resolve the negation against the set of clauses. Since this negated clause directly contradicts one of the clauses in the set, the (unnegated) goal clause is proved.
It turns out that Horn clauses are all you need to express the knowledge you'd like to put into a theorem prover, which is convenient. It's also convenient that if you restrict yourself to Horn clauses -- in particular to one clause with no unnegated literal and the rest with exactly one unnegated literal -- you can solve any solvable theorem-proving problem defined on that knowledge base, and can do so relatively efficiently.
A Prolog system works like this: You provide it with a set of Horn clauses, exactly one of which has no unnegated literals. This particular clause is referred to as the goal and the others are called "hypotheses." The system first resolves the goal with one of the hypotheses to produce a new clause. It then resolves this new clause with another hypothesis to arrive at a new clause, repeating the process until the empty clause is derived. How do you get from theorem proving to enforcing constraints in a set of business rules? Well, it turns out that exactly the same declarative syntax can serve both purposes. The goal member(2 , [1 , 2 , 3 , 4]) . asks Prolog whether 2 is a member of the list, but the goal member(X , [1 , 2 , 3 , 4]) . asks Prolog to find all members of the list. To do some things (consider the reorder business rule previously mentioned) Prolog, or any business rule processing system, will occasionally slip out of paradigm and do something through a side effect.
Back to Mr. Date and his business rules. In section 2 of the book, Date argues that the processing of business rules is an essential part of a different paradigm, one noted for the mathematical purity of its original definition -- the relational database model. An integrity constraint (which is really a business rule) is a conditional expression that must evaluate to true, such as total_owed <= credit_limit. Such constraints, Date argues, are crucial to controlling the correctness of the data.
He then goes on to give an interpretation of the relational model of databases that he never got from the model's creator, E.F. Codd. Date claims, though, that this is what Codd really meant.
A database, Date argues, is best perceived not as a collection of data but as a collection of true propositions. The entire database, in fact, represents a single proposition: the AND of all the propositions in (and applicable to) the database. And the rows of a relational table -- the rows of the relation -- are true assertions about things in the domain of the relation.
Business rules are crucial to the relational model and should be built into the DBMS, Date says, because they are part of what the system understands to be the meaning of the things it deals with. So the system -- the DBMS -- can't do updates to these things properly without knowing and enforcing those constraints. Date quotes Gary Morgenthaler, former Ingres CEO:
Rules...might be seen as finally delivering on a long-unfulfilled promise of the [relational DBMS] revolution -- the ability to move data integrity enforcement...into a location where it can be [applied] across all applications consistently.
In other words, Date concludes, the rule engine ought to be part of the DBMS, specifically the top level of the DBMS, capable of using DB2, Oracle, or whatever back-end database system is desired.
Date thinks that this was more or less the idea all along, that business rule processing is an inherent part of the relational model and of any proper DBMS system, and that DBMS makers got distracted and left out the best part. He'd like to see that oversight rectified.
Me, I'm bemused. I started out following the thread of the conceptual purity of one paradigm -- declarative programming -- and I ended up inside a call to purify a completely different paradigm -- the relational database model -- and restore it to its original intent. And between the one pure vision and the other is the fuzzy realization that the two paradigms aren't as different from one another as they seem. Curious.
DDJ