Declarative programming for business rules, imperative for the rest

I’ve been thinking and reading about declarative programming lately. I have a new theory: it would be possible to write all business specific programming declaratively, and make the imperative code completely business neutral. And I see it opening up all sorts of possibilities.

Ok, so now to explain what I just said.

Programming today is generally imperative. The programmer tells the computer, “do this. Then do this. Then do this.” A list of commands. In imperative programming, we tell the computer how to find the answer.

In declarative programming, on the other hand, the programmer tells the computer what the answer is. That is, we declare what we’re looking for. The computer can find the answer any valid way it wishes. Like in a spreadsheet, we declare the formula for every cell, but the computer can evaluate it in any order.

The problem is that computers can’t run declarative programs. Some programmer has to write some imperative code to interpret the declarative code. They must tell the computer how to achieve the what. In the spreadsheet example, these are the programmers who wrote the spreadsheet.

In practice, a programmer creates a special purpose language and the software to interpret and run that language imperatively. Sometimes this is called a Domain Specific Language, or DSL. Examples of declarative languages are SQL or regular expressions.

So why do I think we could write all business logic declaratively?

The names of the business objects, the language of the domain, changes in every program, or at least in every company or industry. But the fundamental concepts are all the same. Most business programming is about moving around and mutating data. A lot of the rest can be modeled as a workflow engine or even just a finite state machine.

And why do I think this would be a good thing?

It’s mainly about a separation of concerns. The two concepts are fundamentally different. We try to treat business rules and implementation specifics as the same thing, and it muddies the water.

And they need different things. Business rules need to be verified that what they’re modeling is what was intended to be modeled. Imperative code needs to be tested for correctly handling all cases, and for non functional requirements, like performance.

It’s also a code sharing thing. What if we shared all the imperative code? Most free software is business neutral. And with there being no business specific logic, we’re not divulging the secrets of how the company is run.

Declarative code would generally not be shared. That defines how the business does its business. Businesses tend to not want to let that information out, and someone not in their industry probably couldn’t do much with it anyway.

Once we have an ecosystem with some shared declarative languages and multiple interpreters, we can finally have some sort of interoperability. “How would this app work with a different database?” Let’s swap it out and see how it works. “Someone just made a better communication method.” Great, let’s deploy it into our entire software. As long as the new code uses the same declarative language, it can be swapped in.

What do you think? Would the declarative / imperative split solve your problems? Do you think this would (or would not) be a good idea? Tell me in the comments.