For some time now I have been annoying any lawyer or law lecturer within earshot about how we computer geeks have discovered nifty tools to simplify complex systems. In particular I have pointed out that some of these tools could be applied to legal reasoning.
I’m not alone in drawing the analogy between computer programs and legal documents, as this post from NetApp Vice President Dave Hitz demonstrates:
Both legal documents and computer programs are written in a language that looks somewhat like English, but isnt … Ive been reading LEGAL this week, because some friends of mine are writing their will. I agreed to be the trustee in case both parents die while the kids are still young. It occurred to me that the hello world of wills is this:
Leave everything to my spouse. If s/he is dead, then split it evenly among my kids.
This is pretty much what my friends will said, but to express these 83 bytes of idea took 18,700 bytes of LEGAL, for an overhead factor of 225. That is, LEGAL is 51 times less efficient than C.
For my sins the devil set me down to learn law for a bit. I feel somewhat qualified to talk on the subject of legalese as a programming language — as LEGAL.
The problem is not a good comparison. A “hello world” program has a very simple task to perform: take a string of characters, spit it on to the screen, then terminate. It is trivial for a number of reasons, including:
- There is no branching logic (no if-thens),
- The machine-level details are all handled by the language runtime and operating system,
- There’s no accounting for edge cases or error conditions (this is a special case of no branching logic).
LEGAL does not work similarly. Every will document recreates a vast amount of nearly identical text to ensure all the funny edge conditions are covered. And it stays that way because those clauses are court-tested. Sometimes millions of dollars and strong emotions are at stake. Lawyers are naturally reluctant to fiddle.
But! It could be done. The trick is to avoid trying to refactor or redesign LEGAL from within legalese. Dave and others are working at the wrong layer. What is needed first of all is a compiler from a cleaner higher level language down to LEGAL.
It’s a bit like reverse engineering a complex CPU instruction set. A lot like it, actually. Philosophically, the common law is meant to be the discovery of the law, case by case, rather than made or designed. You can think of courts and judges as black boxes. Lawyers are constantly feeding in edge cases to try and map out the internal principles by which such matters are determined, and thanks to the doctrine of stare decisis, they can broadly assume that such principles are deterministic.
LEGAL is in fact not a high-level language as programmers might understand them. It is a reverse-engineered assembler. It operates at a level close to the machine. It has been discovered by the application of tens of thousands of tests over the passage of centuries. Billions of dollars and lives rely on its flawless execution every day, running on a system consisting of millions of distributed units. You can understand why nobody wants to risk a new instruction set when the old one works just fine, thankyou.
But we geeks still have these nifty tools which could be applied. Static checking, unit tests, integration testing et al would be a very useful tool for writing legislation. Any higher level language could recreate the tools for information hiding, loose coupling, tests for complexity, tools for reducing tests and so on and so forth.
Here’s a minor example which provoked my thinking down this path in the first place. In the interpretation of statutes, the question often arises as to whether a list is exhaustive or merely demonstrative (aka inclusive). That is, does the list show every single element belonging to the set, or does it merely demonstrate the properties of items in that set? Does the law apply to only the items on the list, or anything which could have belonged to the list?
It would be nice if we knew up front. In most jurisdictions there are rules of interpretation to tease these issues out, but it would be nice if a higher level language enforced the distinction by requiring a declaration.
Thus this higher level pseudocode:
Party1 is a LegalPerson. Party2 is a LegalPerson. RightsOfParty1 is an ExhaustiveList of Rights belonging to Party1 RightsOfParty1 = Disposal is a Right( "dispose of", between Party1 and any Property ) .... End RightsOfParty1
It might compile down to the usual legalese, like: “The party of the first part, being a legal personality without restriction and of any nature, has the right to the disposal of any property … blah blah … notwithstanding the provisions of the Act, the party of the first part shall possess no other rights in respect of this agreement and waives any other such rights, whether implied or express …”
Of course this is a messy project, not least because such a language necessarily needs to work with the legal concepts as first-class elements. Then we need to avoid the nightmare of COBOL11. An aside on capitalisation: Notice how he calls it LEGAL, by the way? This is probably harking back to the early days of programming when most languages were spelled in upper case: FORTRAN, LISP and COBOL for example. [↩].
Anyway, it’s fun to ruminate about.