waffle

Today was perhaps the fifth time I went back and read up on Intentional Programming. It’s the brainchild of Charles Simonyi. (He happens to have invented the often misunderstood concept of hungarian notation — if you think it’s horrible, you’re probably just applying it horribly — and if I wanted to be facetious I could claim that Intentional Programming was his way of trying to make up for it, but I don’t, so I won’t.)

Intentional Programming sounds completely ludicrous to any seasoned programmer. It’s about writing code that describes intent — instructions that read “print the numbers 1 to 10″ — instead of turing machine-centric imperatives — instructions that read “let i be 1, while i is less than 11, print i and then increment i by 1″. It’s ludicrous because it shouldn’t work, because if it would, it would have been implemented ages ago and we’d all be much happier. This is not a new problem. Yet Simonyi seems to have made it work somehow.

The core of the implementation of the idea is simple and compelling: start with describing the problem. Too many issues happen when you translate business logic — the thing that the program should do — to programming logic — the thing that the program tells the turing machine to perform in order to actually do this as a side effect. As the number of people that have to interact on these layers goes up, so does complexity, and so does the likelihood of someone translating something wrong, or of conflicting rules appearing. By first defining the problem as a set of interconnecting objects and rules, you short-circuit the problem.

Now that you have the appropriate building blocks, you can start writing the logic in a domain specific language. Here’s where the reception gets fuzzy. Apparently, the logic will be generated to compilable code. Apparently, this has gone far enough that a system for managing or somehow calculating pensions has been built by CapGemini, and apparently, the people can now enter their rules in the same way that they laid out their logic in Excel spreadsheets, only now the program is actually written for them by implication. But that’s mostly all we know.

It stands to reason that this way of solving the problem would work. If translation tends to fuck up the logic, stop translating, or at least invent a better, controlled way of translating. If you can rid the world of horrible Access/Excel/VBA “apps” where “everyone’s a programmer!”, so much the better. (I’m not opposed to solving those problems. I’m opposed to solving those problems in a way that makes the solvers half-assed practitioners of my craft, instead of practitioners of their own craft or even a new craft.)

Intentional Programming will hopefully play itself out over the next few years and give us an opportunity to watch. I could choose to focus on the difficulty of engineering decisions without an engineer at the helm at all times (how are the generated programs with respect to parallelism? speed? memory usage? how do you optimize or debug such a program?), but I’m instead just gleeful that anyone’s working on solving the underlying problem. This seems to be common case these days, what with MagLev and all. (Relational databases really heavy? Let’s throw them out and just use native objects. You’re going to use native objects anyway; let’s use them in a way that scales.)

And hopefully, it’s part of the ongoing shift towards asking “what?” instead of asking “how?”.