This is quite a misunderstanding of how the law actually works, probably enhanced by lots of lawyer TV emphasizing obscure wording tricks.
In reality, laws are already written in a relatively normal language, and the words almost always mean exactly what they mean in plain English. The only problem is that the legal concepts they describe are themselves complex, and often they end up in a tangle of references to other laws and regulations and legal precedent etc.
IANAL but from my experience reading laws, they're written in a way that looks like it's trying to replicate programming-language-esque nested logic, but in prose format—instead of using physical layout to establish the relationships between concepts, they use words, which I find more confusing. I would rather read laws written in a more structured format.
You (as a software engineer or similar) have been trained to read the 'more structured format' you'd prefer; lawyers have been trained to read 'prose'.
Don't get me wrong I'd prefer it too, I just recognise it's a consequence of my own education and experience, and if we somehow flipped the switch overnight most lawyers would be completely baffled and pining for the much clearer old way.
The US Code is divided into numbered titles, sections, paragraphs and subparagraphs which can link to and incorporate each other by reference. This tree structure is reflected in typographic conventions which visually distinguish operative provisions from headings, indices and editorial notes. Isn't this the same kind of "structured format" as a code repository made up of libraries, modules, source files and functions?
If you read almost any state or federal statute, it's usually presented online in a tree format where definitions link to the defining article and referenced articles are hyperlinks to those sections.
But all structured format use words, and they're many programming language that are prose since COBOL. No one want to write laws in APL or assembly like.
> As a fun exercises, try to find how many definitions of “child” there are in the US law and how many times it’s used undefined.
I don't see how a language is going to solve this. This isn't really an issue of language, it's an issue with ambiguity in the very intent itself. That's why we have judges, who interpret that intent.
Indeed. Ambiguity in legal codes is a feature that allows them to remain relevant for more than a couple of years, and the formal-law "utopia" that some commenters here appear to desire would be a nightmare if put into practice.
Personally I'd rather have laws that work, are consistent and easily understood if you can follow 'if A then B' logic, even if they have to be updated more often.
Relying on ambiguity is admitting there are no laws, and we rely on the common sense of the people in thr judicial system.
> Relying on ambiguity is admitting there are no laws, and we rely on the common sense of the people in thr judicial system.
What's better:
- relying on the common sense of the people in the judicial system to interpret the intent of the law as it applies to a particular situation,
- or relying on the common sense of legislators to write a precise, unambiguous law that will cover all possible situations without negative unintended consequences, and without the law-writing process being influenced by spureous interests and pressures?
The answer highlight why the law is interpreted as is now, with a body of trained public servants analyzing the particulars of each situation, rather than by fanatics trying to follow the letter of the law.
Languages like this may help clarify the intent of legislators so that it is not twisted by clever lawyers; but a human reviewer should always check the relevance of one law to any particular case, and wether the text corresponds to the original intent as applied to a given situation.
This is a solved program in programming, you hover Child and hit "Go to definition". If it's ambiguous, the lawmakers would get a compile error instead of pushing a broken law. They may even have to pay us for consulting to fix it, depending on how esotrtic the language is, how nice is that!
Legal codes aren't meant to work like programming languages. It is impossible for a legislator to predict how the world will work when their law is applied, and it is highly unlikely that they will anticipate every situation and context in which their law will be invoked.
Judges and juries and lawyers all exist to help us interpret the inexact legal code in a way that is (hopefully usually; but obviously not always) fair and reasonable given the often-nuanced situations at hand.
That doesn't add up with how the average piece of legal code looks. Even when I read a brand new piece of legislature it's an impossible soup of words, attempting to document every possible edge case the legislators thought of. If the point was to leave room for interpretation by a judge and you concede yoy don't have full context of how what you're writing will be applied, surely you could write much more sensible and human-readable text.
It adds up to how the average piece of legal code works in practice.
Law is political. It's persuasive, not deterministic. It often comes down to a judgment based on the relative political power of the entities in question.
Even if you find a statute that says very clearly that X is unlawful, there will be situations where a lawyer will argue that it isn't.
Sometimes they'll make that case successfully - for various possible reasons, not all of which will be lawful themselves.
This is one reason why statute law is expanded by case law. And good luck trying to automate case law.
I would be happy if the law conforms to other existing laws, not future edge cases. The solution being proposed here would do that, while the existing system would not.
> As a fun exercises, try to find how many definitions of “child” there are in the US law and how many times it’s used undefined.
Which is why it is the common standard in German law to define every possibly unclear term either in the relevant section of the law itself or in an introduction article.
It's the standard in the US, too, but "child" is a case where plenty of lawmakers have assumed it couldn't possibly be misunderstood, while plenty of others have defined it with contradictory definitions in their respective sections.
The latter is better than the former, but it also makes it even harder to interpret sections with no definition.
I don't agree that the law is a huge mess. It is certainly far less of a mess than any code base I've ever seen, given the gigantic scope of what it applies to, and how many people if affects.
Note that the legal system is indeed a huge mess, but that happens because of many other reasons - not a problem with the wording or vagueness of the law, but with the explicit (malicious) intentions of law-makers, judges, police and others involved in the whole process.
For your example of "child": how often does it actually cause a problem in practice? How many people have been improperly punsihed/set free because of a poor interpretation of the word "child" in a specific law? This is far more relevant than every law taking up valuable space to define what such a common word means.
> How many people have been improperly punsihed/set free because of a poor interpretation of the word "child" in a specific law?
How many improperly punished people is good enough? How many cases go to Supreme Court because the amount of needless ambiguity just adds up, one word at a time?
> This is far more relevant than every law taking up valuable space to define what such a common word means.
I don't know how many is good enough. If it's every other person, than that's bad; if it's two people since the law was written 50 years ago, I would say that's good enough in my book. Which is it?
And no, cases don't often make it to the Supreme Court because the wording of the law is ambiguous. They make it to the SC because the parties disagree on legal principles and on whether laws are unconstituional or not.
> Right? Why do many laws redefine it?
I would have to see some specific examples to judge for myself. Still, this seems to be the opposite problem compared to what was raised earlier. So which is it? Do we want laws to be more explicit about their exact definitions of words, or more implicit?
> And no, cases don't often make it to the Supreme Court because the wording of the law is ambiguous. They make it to the SC because the parties disagree on legal principles and on whether laws are unconstituional or not.
I'm not from your legal system, and yet even I know that's not right: they make it the SC because the 'losing' party disagrees with a lower judge's decision that's already been made, and makes an argument compelling enough in appealing it that it needs to be reconsidered. (A few times, to get as far as the SC, probably.) That almost has to be because of some 'ambiguity' - the lower judge decided one way and the appeal is 'well no I don't think that's the correct reading'.
The GP is taking a restricted meaning of "ambiguity", where the ambiguity is within the laws relevant to the case being appealed.
But cases that go to the Supreme Court of the United States are often cases where the "ambiguity" is on how the US constitution should be interpreted and applied.
In a practical sense you're not going to be able to codify the US constitution into code. It's even a well received "feature" that constitutions are sometimes a bit ambiguous, see: https://en.wikipedia.org/wiki/Living_Constitution
Note that the SC almost by definition only looks at cases that pertain to the constitution, or to base legal principles, not to individual laws. And good luck codifying the constitution itself and/or the rules of common law into formal math.
Also, appeals essentially mean that at least one of the parties believes that a judge made a mistake in the way they applied the law, not necessarily that the law itself is ambiguous. A judge can fail to apply a perfectly unambiguous law, or at least a plaintiff can believe that they did, and can bring enough evidence that their belief has some merit.
> And no, cases don't often make it to the Supreme Court because the wording of the law is ambiguous. They make it to the SC because the parties disagree on legal principles and on whether laws are unconstituional or not.
I don’t see how those are exclusionary principles. Also, I have never heard about this case, but after some simple googling I learned that the Supreme Court indeed had to figure out the definition for children in a particular law: https://berkeleysolicitors.ie/supreme-court-determines-defin...
> Still, this seems to be the opposite problem compared to what was raised earlier.
No, it is the same problem I mentioned before: some laws define it in a contradictory way; some laws don’t define it. I told you it’s a fun exercise!
> Do we want laws to be more explicit about their exact definitions of words, or more implicit?
I want laws to make sense. Inconsistency doesn’t make sense and only brings troubles. Vagueness is good. Ambiguity is bad.
How do you codify the effects of judicial review? What if the court's decision is not binding but is still persuasive -- such as when it's a decision from another jurisdiction?
Common law has like 800 years of tech debt. It's turtles all the way down. And by turtles I mean precedent, and not all of them are compatible.
None of what I've described is malicious. It's just what happens when law meets the messiness of the real world.
This is the real advantage of codifying law into a programming language. You can have validation and assertion that is automated. And a strict structure, free from ambiguity.
As an additional advantage, multilingualism becomes more accessible, with the codified program/definition acting as the lingua franca of law. Thus, someone who only knows English could make sense of Japanese laws by reading it.
I cannot imagine some system that goes from a formal language to reality not having ambiguity. Even going from mathematical formalism to mathematical truth you can’t get all the truth. I imagine getting all the justice would be harder.
And I have heard lawyers explain that sometimes ambiguity, in contracts at least, is a good thing as it reduces the amount of a priori negotiation for low probability events. The the low probability event happens and the contract is ambiguous then you negotiate at that time and maybe sue.
And for laws, I think a bit of flex in the system probably would be a good thing. Give some scope for local judgment an autonomy to the people closest to the situation.
Why would you want every law that applies to children to explain what a child is? Why stop at child, perhaps each law should include a definition of every word it contains, right? That would certainly make every law much more readable for the masses.
The text of the law is meant to be understood by the people that it applies to, i.e. everyone living in the locality which passed said law. Expressing law in a formal language goes directly against that goal. Imagine if a EULA you get presented with, instead of being a wall of repetitive text, would be a wall of code with symbols you at best remember from some class you took in 8th grade.
Having EULAs and many types of contract be code would be a huge upgrade.
For one, it'd make them a lot shorter. You could use inheritance or composition to refactor out repetitive boilerplate, which is 90% of what EULAs are. The thing you see would only be the places where it deviates from a base EULA that you could study once.
For another, it would catch bugs automatically. I have caught bugs in contracts drafted by lawyers a bunch of times, just by reading them carefully. For example numbers that are stated in both words and digits but they don't match. References to clauses that no longer exist. Statements that are contradictory.
A properly written language could be compiled to English for people who for some reason can't read the "real" language. But a well written PL for law would be quite readable.
Programming languages and other formal languages add boilerplate, they never remove it. Compare pseudocode for an algorithm with the actual implementation: it will almost always be much shorter.
All of the rest of what you mention could be achieved with plain language contracts exactly as well. Nothing prevents the software industry from getting together and producing a base EULA that all others refer.
Except of course for the fact that it would be utterly impossible to convince companies to agree to such an endeavor, whether in code or plain language or any other way. Especially since the purpose of EULAs is not to be clear, but to confuse end users with verbiage.
I don't watch that kind of television much, but since I'm not a lawyer, my view of the world is probably too simplistic.
Still I'd argue that normal language is very poor at handling that tangle of references.
A good programming language would make those references very easy to untangle and present in their untangled form.
When I've read (Danish) laws, I've often thought that they would read better as if statements.
It's not that I think those laws are written in legalese, it's that they are expressing logic in a suboptimal way. Like how "four plus four equals eight" is a suboptimal way to express what could be expressed with 4+4=8.
> A good programming language would make those references very easy to untangle and present in their untangled form.
Not necessarily. Notation can only do so much to help with understanding. To understand 4+4=8 you still need to understand what's a number, what addition means, and what it means for two numbers to be equal. The same problem applies to the law, and it takes far more time to understand legal concepts than the actual wording.
Additionally, the law is not supposed to be some arcane discipline that you need to learn a new language for. The law is decided on by, and applies to, people who are not and have no reason to become legal experts. It is simply a statement of the rules by which we try to live.
If laws were written in code, they would actually become much, much harder to understand than they already are for the vast majority of their audience. Imagine a public debate about a law where the text of the law was, instead of plain(ish) English, Haskell code. Imagine news anchors explaining that Biden agreed to add the lambda sign, but was heavily criticized by McConnell for his use of a monad instead of a plain for loop.
> Additionally, the law is not supposed to be some arcane discipline that you need to learn a new language for.
It would seem to me that reading laws has become an arcane discipline, partly due to it being expressed in a language with overly long sentences, which handles branches and references very poorly from a readability perspective.
> Imagine news anchors explaining that Biden agreed to add the lambda sign, but was heavily criticized by McConnell for his use of a monad instead of a plain for loop.
While that would surely be interesting to watch, I think we both know that's not what would happen.
Like I wouldn't ask you "number four plus sign number four equal sign X?"
I assure you that no one who fails to parse long sentences would get a better understanding from replacing those with code of all things.
And if the actual text of the law consisted of coding symbols, I very much expect that (a) you'd have endless debates about the precise symbols being used, and (b) have to have anchors going over the meaning of those symbols and losing 9/10ths of their audience along the way.
If a word is used with a precise formal meaning, than it is a symbol more than a word. For example, "for" in C isn't the English word "for", it is a symbol for a precisely defined operation. Someone who speaks native English couldn't understand what `for (;;){}` means.
I think this is a big part of it. My sense (as a non-lawyer who has looked at a fair number of laws and contracts) is that, in addition, there are plenty of laws and contracts that are just poorly written and wording or constructions that lawyers have retained out of caution or traditionalism. This last case, traditionalism and caution, is maybe a special case of the other cases, but it's not always obvious.
I believe that another thing that happens, and it is common in every field, is that certain constructions are very common within the field, and so the need arises among practitioners to shorten them. Most domains invent new words, but this doesn't work for laws and contracts (since they need to at least in principle be understandable to non-practitioners, such as most elected officials).
So instead of full-on jargon, legal texts get enshrined phrases, which practitioners can essentially skip over, but which also retain some meaning in plain English (though often sounding antiquated).
A contract is anything two parties agree to with some consideration (benefit) exchanged. The law does not distinguish between 'proper' contracts and informal ones (like a handshake) except a proper one may be quicker to execute. And this is a feature... You wouldn't want to force everyone to undertake the cost of developing highly specialized legal products just to do business.
I worked for a company that translated certain kinds of legal contract into what was effectively a DSL. They could then be represented in a simplified way. That was the whole business.
The CEO (a lawyer) claimed that the lawyers who wrote these things would deliberately and unnecesarily overcomplicate them so that they could maximize billable hours.
I think they could quite easily have been templated using a DSL but that DSL would need frequent maintenance. These types of contracts did evolve as new types of clauses and legal constructs popped up and gradually evolved from "new" to "standard" to "boilerplate".
The text of a contract can either be long and very explicit, or short but full of implicit assumptions. A DSL is the second kind: you encode those assumptions I the structure of the DSL and the text as written is based on all of those assumptions.
The problem than becomes that anyone who wants to understand the contract now has to read not just the contract as written, but also all of the definition of the DSL itself. This can actually be OK if the DSL is very commonly used, such as a DSL for contracts between two parties which sign new contracts every day.
But it is a huge waste of time for parties which rarely sign contacts, and is often used as an explicit moat to keep laymen from participating. If I give you a contract to sign that isn't even written in plain English, you will have no choice but to hire a lawyer specialized in understanding this contract DSL to advocate for you.
I imagine (savvy) lawyers actually love DSLs that purport to make contracts concise.
If you can't read documents in whatever form for their legal meaning, you can't work around the need for a lawyer. The DSL may be defined in comprehensible enough language and texts in it may be interpretable easily enough; but the method of contract is determined by agreement of its parties (inside the bounds set by law).
Currently, contracts are judged by their meaning in plain English, with any additional definitions being stipulated in the contract itself (either explicitly or as part of the verbal agreements that accompanied the negotiation of the contract).
A DSL is an extra layer of abstraction above that. If you agree to a contract written in some DSL, then you must also agree to the way that DSL translates into plain English. To significantly compress a legal contract that is not deliberately written to obfuscate its meaning, the DSL has to pack a lot of precise meanings into every term, making it very dense and hard to parse unless you're well-versed in it.
That's absolutely not correct. A DSL is not necessarily short and implicit. It can be very implicit or very explicit and the one I worked on was explicit. Its defining feature would be that it is straitjacketed.
The customers in our case did not actually look at the DSL - it was entirely internal. We decompiled the legal document into the DSL so that we could then represent the contract in more understandable ways.
I don't know if what you say about laws is correct, but it's certainly not a correct description of contracts. The general public is constantly confronted with utterly unreasonable legal documents: far too long, far too unclear, far too complex. The lawyers writing these, and the entities paying them, both know that the public will never read or understand them. It's pure cinicism.
I don't think so. Any state progressive enough to adopt law-as-code might also put in place laws limiting the length and complexity of the code. It would be easier to control this aspect as code I believe.
By that same token, any state progressive enough to think about law-as-code might first put in place measures to limit the length and complexity of contracts written in plain language as well.
The problem here is the length and complexity, not the language used to express the contract. And note that law-as-code would necessarily mean that a layman is fully unable to understand a contract (or the text of a law) at all. They would be fully reliant on a specialized worker to explain the code to them in plain English. Current contracts, if you have the patience to read and map them in full, are fully understandable by anyone with a good knowledge of the English language.
It does, to some extent, but it's still much closer to natural language than code. Expressing the law in code would turn this dial up to 11 and then some.
Sure, but there would be all manner of services that could automatically translate law-in-code to any human language you wanted. The best part is that you could easily and automatically translate a law into, say, English, Japanese, and German. Whenever the law-in-code source changes, just rerun your translator and voila: no human intervention required (meaning faster and more accurate translations of the law into human-readable language).
You could even program the "law-in-code-to-humanspeak" translator to generate different levels of the target languages, e.g. translate into something at a 6th grade reading level vs. something at a grad school level. Again, the advantage would be the automaticity.
But now instead of reading the laws that govern my life myself and understanding them, I have to rely on some third party to explain to me what laws my representatives are voting on.
Is that supposed to be very complex legal language? I'm not sure if this is some reference I'm missing, but it sounds relatively simple to me: it seems to be an accusation that someone is providing services dis-honestly (i.e. hiding some aspect of how the service will be performed or how much it will cost).
The full scope of what that encompasses is very hard to know, as it depends on essentially every other regulation and common law practice and precedent that applies in the particular legal jurisdiction (and which jurisdiction that is can itself be a somewhat thorny issue).
But this problem isn't solvable by code. It's part of the intrinsic complexity of the legal system.
> For the purposes of this chapter, the term “scheme or artifice to defraud” includes a scheme or artifice to deprive another of the intangible right of honest services.
In reality, laws are already written in a relatively normal language, and the words almost always mean exactly what they mean in plain English. The only problem is that the legal concepts they describe are themselves complex, and often they end up in a tangle of references to other laws and regulations and legal precedent etc.