In our society, we’ve developed structures pursuant to this. Our legal code is not composed in generally-readable natural language, but in a special tongue called legalese. While the term “legalese” is often used humorously or critically, in the context of lawyers run amok, there are good reasons for us to use such a precise language in a legal context. In law – as well as legal decisions, briefs &c – precise, unambiguous language is the goal, even at the expense of general legibility. In legalese, we see several features that are often found in computer code. Ambiguous terms are often declared at the beginning, or, sometimes, upon first usage. Sometimes, terms of art are imported from other documents: laws, judicial judgements, or other works.
Given the nature of law, perhaps we should try and think of law more like software, and less like language? Specifically in the realm of legislation, though, to a lesser extent, also in the realms of judicial opinions, briefs, contracts and so on, we need robust, functional language, without errors, bugs, or loopholes. Lawyers, legislators, judges, and law professors – despite years of practice – have made only a little progress in this respect. Laws remain as problem-ridden as ever. At CITP discusions, we often speak about some aspect of a piece of legislation as being a “bug”, or debating whether some “feature” is having unintended consequences.
Computer scientists, on the other hand, have made a lot of progress in determining what constitutes good software. We understand that abstraction is key; we know how to create standard interfaces, and define robust data-types. This is not to say that all software is good software, but at least we have standards for writing good software, and we can tell the difference between good and bad. Perhaps, if we wrote law with some of the best practices we use when writing software, we could get better results.