Blog‎ > ‎

The Case For Declarative Transaction Logic - part 2

THIS PART IS NOT YET FINISHED

In part 1 of this article, we saw that spreadsheets are a pretty nifty invention, and that maybe we could use similar principles in transactional systems.

In this second half, we'll see how this works.

It starts with simple formulas

We're all familiar with basic spreadsheet formulas. A simple one might be something like:

= C2 + D2

which specifies that the value of a given cell should be derived from adding the values of cells C2 and D2.

Implied in this specification is that, any time C2 or D2 changes, the value of our cell should be recomputed. I know it sounds blindingly obvious, but bear with me.

Another slightly more complex spreadsheet formula might be:

= SUM(C2:C20)

which specifies that the value of this cell is the sum total of cells C2 through C20. Once again, we have specified what the data should be without specifying how the data should be computed. It's implicit in the declaration: the spreadsheet simply knows that, if any cell between C2 and C20 changes, the sum should be recomputed.

At this point, I'd like to draw your attention to the fact that, given nothing more than these two patterns (and a few more operators like multiplication and division), you could already create a spreadsheet of significant complexity, and in fact do most of a non-trivial tax return. That's because, if you take a bunch of very simple things and make them depend on each other, you always get a complex system.

In fact, one common problem with spreadsheets is that they're so easy to do, it's not hard to go crazy and create a spreadsheet that's so complex that it becomes very difficult to understand.

Dependencies made easy

So how does a spreadsheet recompute itself? It's really not that hard: it looks at all the formulas, sums and so on, and generates a dependency graph. It then uses that dependency graph to determine what needs to be recomputed when something changes. This is a recursive process: changes beget changes, which themselves beget more changes, etc... 

There are of course limitations. We've all seen Excel tie itself into knots because of self-referential formulas. Some recursion is possible, but most of the time you'll want to stay away from self-referential definitions.

At the risk of repeating myself, I will now reassert the crucial point of this article. Having the computer deal with the interdependencies between all the bits of logic is what makes spreadsheets so easy to use, and so powerful. I cannot emphasize that enough.

Declaring transaction logic

We can use the same approach to declare what our data should be.

Comments