Imperatives and Declaratives

  • September 21, 2012
  • Scott

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)

Related Posts
  • July 16, 2018
  • Ariana

Driven 2018 is coming up quick and we wanted to share some of our most anticipated sessions with you. You can ...

  • July 15, 2018
  • Scott

From nearly the first year I began writing this blog on behalf of BP3, pundits and commentators have predicted...

  • July 9, 2018
  • Ariana

We are excited to announce Automation Anywhere will be sponsoring Driven 2018. Automation Anywhere will be...

  • Pingback: BPM Quotes of the week « Adam Deane()

  • It is not a declarative language that will deliver it is a
    declarative “technique”. This was the one of the fundamentals to our
    early research to “solve” the business software problem! The other
    key principle is People are the source of all information and when analysis was
    carried out believe it or not there are less than 13 task types (including the
    UI), human and system that support people at work. (So why are we still coding?)
    These can be expressed as data “objects” inside RDBMS ready to be configured. Then
    there is the power in linking the tasks in any required order which enhanced
    the rules capability. By taking this approach you effectively separate business
    logic from delivery technologies.

    It was after this core capability was built we built a
    graphical interface a where business professionals not coders can quickly build
    any process application. This is where at a click of a button the configuration
    built in the “map” is declared through to the database and with a process
    engine it sets up automatically the application ready to run. There is no
    intervening “interpretation language” to inhibit performance or scale. The result
    is game changing maybe too game changing! The time to build is dramatically cut
    where core code does not need to change and no code generation or compiling making it easy to change in build and in the

    • I think you’re on to something in the first sentence, “technique” vs. “language”.
      The second paragraph, unfortunately, sounds a lot like other bpm tools i’ve used. For example, one of the market leading tools requires no compilation, everything gets stored and versioned in a DB and it does a good job of genericizing task types. But businesses keep coming up with requirements that would require writing some code 🙂

      If you have something we can take for a test drive let me know!