Imperatives and Declaratives
- September 21, 2012
- 3 Comments
Keith Swenson has a pretty interesting post on the possible use of declarative language to describe process, based on what he heard at BPM2012.
Technically, BPMN is a hybrid of declarative and imperative (much like make or ant)- because you can combine strict control flow – do this, then this, then this – with event-driven elements that do not dictate control (the when or the ordering). But the definition offered at BPM2012 that Keith quotes is a good way to divide the two approaches:
Someone at BPM 2012 described imperative modeling as: “everything is illegal except the actions explicitly allowed by the process” while declarative modeling is “everything is allowed except those actions that are explicitly prohibited by the model.”
It is a pretty fascinating read, overall, but a couple words of caution. First, a software program that appears to be “declarative” to the user (everything is allowed), can easily be written by an imperative programming language. It doesn’t seem to make sense, but if you’ve used MS Word lately, or MS Excel, or Powerpoint, then you know this is true, as they were all written with imperative languages.
Bringing it back to BPM: we can still create a declarative “system” for the user, while the underpinnings are described by BPMN. The users wouldn’t be using BPMN, any more than the users of MS Word use C++ or .NET.
Second issue: Declarative language. Now, setting BPMN aside. Let’s presume we’ll build the solution in a declarative language. Who is “we”? If “we” is the end-user, we’ll have massive education issues (declarative languages are, generally speaking, harder for mortals to understand than imperative languages). Don’t believe me? Try debugging a 10,000 line prolog program, and then try debugging a 10,000 line C or Java program. Totally different endeavor.
Even for developers, declarative languages present some challenges. In the 90’s I worked with a language we called CML (configuration modeling language or constraint modeling language, no one was really sure which!). It was amazingly efficient for representing constraint-based configuration systems. In particular, it was declarative by default (though you could specify a collection of actions that would happen in order, that ordering was a minor part of the language). It was so efficient that hundreds of people maintaining rules systems were replaced by a few high-end configuration specialists writing these configuration models. But these specialists were PhD-level or masters-level in computer science and engineering degrees in order to understand the models they were building. It wasn’t what you call “highly accessible” technology.
Perhaps a simple business-accessible declarative language can be developed. But as Keith notes, a rule-based system won’t cut it (validation and correctness and consistency are hard to maintain on a large rule set for an inexpert user).
Keith sums it up perfectly here:
My remaining question: if a declarative modeling language is discovered, can such a declarative language be easy enough for doctors and lawyers to use directly? It is not clear to me whether this will be possible, but we should remain vigilant looking for such a language that might be suitable for ACM.
(Or more generally, for such a language that might be suitable for doctors and lawyers and business users in general)