Comment by gnicholas | Hacker News Reader

Comment by gnicholas | Hacker News Reader

The title of this HN post, like nearly every headline I've seen for this lawsuit, is misleading. The headlines makes it seem as if the company forgot an Oxford comma and is now losing millions as a result of having made a typographical error.

This is not the case. There is a statute that does not have a comma where one might be, and the litigants fought over whether the lack of a comma toward the end of a list ought to be read in light of the Oxford comma convention or not.

And it's actually more complicated, as the last item in the list is (potentially) compound, which makes it difficult to tell whether the "and" is to be attached to the final element alone, or to be a binding of the final element and previous elements.

Not that this its uncommon for articles to have misleading headlines, but I've been surprised at the extent to which nearly every article (save this one [1], by the ever-precise law professors at the Volokh Conspiracy) have misrepresented the case (or misunderstood it?) to make it seem like a company's typo led to a million dollar loss.

1: https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...

The headline does not suggest or imply that lack of a comma in a document the company itself drafted is the basis for the overtime liability--only that the company may suffer the consequences.

When something is said to be "lacking", it implies that something should be there but isn't. The headline only introduces one actor — the company. In this context, there is only one party to put fault on for the "lack" of the comma, which is the company.

When you read the article, you see that the comma is not from a company document, but from a statute. So the "lack" is due to legislative drafting. But reading just the headline, how could one have imagined that the "lack" was due to an unnamed actor that drafted an unnamed statute?

While the implication I described is not the clearest implication, there is no way a reader could see this headline and have any clue that what really happened was:

Legislators drafted ambiguous statute and company's interpretation lost out

But that would make for a lousy headline, I suppose.

I initially guessed it was a tax law that got them. Never occurred to me that it might be something that the company did - typically they have lawyers who comb extra well for that kind of detail, even in a $1200/month lease. Lord knows what they do for multi-million contracts...

I read the headline and figured it was ambiguity in the law. I think the headline is fine.

Impressive! The headline doesn't mention a law. Anyway, do you think the headline could be better?

"Law's Lack of ..." would maybe help, but I don't think it's necessary. I figured it was a law, or a regulation, because where else are the exact semantics of the written word so important that it could cost a company money?

A contract.

Fair point. But I still think it's a fine headline. Any ambiguity is quickly resolved in the article - headlines can't convey everything, and I think it says the most important part.

That's a fair point, but I think calling the headline "misleading" goes too far. My own reaction to reading the title was not to assume the subject was to blame for its own troubles: that's certainly a possibility, but it could just as well be some "lack" in the environment, as turned out to be the case. Perhaps it says more about the mindset of the reader than the headline in itself.

As the article illustrates, our languages are full of ambiguities. Human communication is limited in bandwidth and which features are preserved when we use lossy compression to shrink an article to a summary or title depends on priorities. For example, your suggestion:

> Legislators drafted ambiguous statute and company's interpretation lost out

emphasizes who is at fault, business or government, but loses what the dispute was (overtime pay), where the case was located (Maine), why there was ambiguity (the Oxford comma or lack thereof), and how much was at stake (millions of dollars). There's also something to be said about making it sound catchy (like the alliteration with "Maine" and "millions").

You could put all that back in, of course, but at the cost of more bandwidth consumption. And since everyone has different priorities (for example, someone else might want to know that the company was in the dairy business), there's always more to add until we reach the point where we're just reading the entire article.

So yeah, that's a good insight, but the top HN comment shouldn't be that the article's headline could be interpreted differently.

I am also surprised my comment is at the top of the page — I think this is partly due to the subthread on computational lawyering.

Good points, and thanks for your thoughtfulness. I agree that "misleading" could be a tad too emphatic, and I'd be open to other descriptors that might be more accurate.

I think you meant:

Legislators drafted ambiguous statute, and company's interpretation lost out. ;)

>When something is said to be "lacking", it implies that something should be there but isn't.

I don't consider "lacking" to have that implication. Especially not in the context of the Oxford comma, as lack of an Oxford comma is well known to be a source of ambiguity(1).

(1) https://theliteraryman.files.wordpress.com/2012/06/comma-com...

Why on earth not to use programming language like constructs to write legal documents.

No compiler or anyone who can read code ever had any ambiguity reading simple code.

let overtime_allowed = true unless (action in [canning, processing, preserving, freezing, drying, marketing, storing, packing_for (shipment or distribution)] of [Agricultural produce, Meat and fish products, Perishable foods])

There's an argument to be made that it already is. It's called lawyerese (or just L), its programmers are highly regulated and highly paid.

What happened here is what happens when someone with insufficient skill tries to write an L program. The language has no such thing as linting or syntax checking, so while a faulty program will always run, it will return with unexpected or absurd results. L failures tend to make C's nasal demons look positively friendly by comparison.

There's no formal spec, it's literally centuries of ad-hoc patches and fixes and revisions piled onto one another.

That's not what happened in this case. The statute was written in accordance with the style guide, which made it ambiguous, which is why it went to court in the first place.

> What happened here is what happens when someone with insufficient skill tries to write an L program. The language has no such thing as linting or syntax checking, so while a faulty program will always run, it will return with unexpected or absurd results. L failures tend to make C's nasal demons look positively friendly by comparison.

Worse than that, legal "code" has thousands of frequently used implementations (judges) and millions of one-time-use implementations (jurors), all of which may interpret it differently, both from each other and even from their own past versions. So if you thought writing JavaScript was bad because you have to deal with a half-dozen browser implementations and quirks...

Jurors don't interpret law and judges have a well-organised system for exception handling.

The legal system is massively reliable. By the time something reaches an appeal court, you're already into 5th 9 territory. You can live an entire life under it, moving through it, completely surrounded by it, and never have to see it or think about it.

> Jurors don't interpret law

They can and do. Quoting the Oregon constitution:

"In all criminal cases whatever, the jury shall have the right to determine the law, and the facts under the direction of the Court as to the law, and the right of new trial, as in civil cases."

Similar measures exist in other legal jurisdictions, though it isn't universal.

> judges have a well-organised system for exception handling

I didn't suggest they don't; I suggested that two different judges can interpret the law differently.

> under the direction of the Court as to the law

The point here is that jurors decide on facts according to law, as instructed by a judge[0]. The judge is also asked during trial to consider legal questions -- not the jurors.

> I suggested that two different judges can interpret the law differently.

I suggested that is why there is a hierarchy of courts, with the hardest and most important ones being delegated upwards via the process of appeal.

I am, of course, not a lawyer and this isn't legal advice. I did enjoy my time in law school though. The main thing I learned is that the law is a language that resembles but is not common English. Phrases like the one you quoted have to be read in the larger context of case law and statute law.

[0] http://www.americanbar.org/groups/public_education/resources...

Interesting idea, short googling lead me here: "Computational Law is a branch of Legal Informatics concerned with the mechanization of legal reasoning (whether done by humans or by computers).[1] It emphasizes explicit behavioral constraints and eschews implicit rules of conduct. Importantly, there is a commitment to a level of rigor in specifying laws that is sufficient to support entirely mechanical processing."

https://en.wikipedia.org/wiki/Computational_law

Code is very often ambiguous with respect to the coder's intent. I've seen plenty of bugs because the coder inadvertently used `=` instead of `==` (or `==` instead of `===`) or left out parentheses in conditionals (`!w || x && y || z`).

The nice thing about code is that we can reveal bugs by executing the code and comparing the results with our expectations. Ideally, we do this with lots of testing. But even then, there's a hole in coverage and bugs make it into prod and cost someone lots of money. Which is basically what happened here.

If that were the case, following the "spirit of the law" would become basically moot and writing legal documents would become significantly more involved.

As a former freelancer, being able to write a simple business agreement and explain good faith to clients was empowering. None of my clients could have afforded to compensate me for hiring a lawyer to write in legalese, and would have been put off at such lengthy contracts despite the relatively straightforward projects.

I think people get the wrong impression about things too, because your story is definitely the more common one than the article. Of course, no one goes around writing articles about the peaceful and uneventful transfer of property or rights, so there's a skewed perception of the risks.

Because law is written to allow for interpretation when unforeseen circumstances are encountered.

Usually with the aim to maintain consistency with the intent of the law. If the intent is ambiguous, you can't easily do that (as this case demonstrates). A formally defined Controlled Natural Language[0] would be ideal for situations like this. Arguably "Legalese" already is it's own form of CNL, albeit not very well controlled.

[0] https://en.wikipedia.org/wiki/Controlled_natural_language

I think you meant to allow for big payday for lawyers to argue about for a decade or so

Or even better, come up with punctuation that supports nesting and makes grouping clear. So you could literally reuse the language, but surround each term in the list in { ... } or something similar.

Ethereum tried this, and a bug in the code lead to millions of dollars of value lost. They ended up hard-forking the code by changing it to match the intended outcome of the code, thus reversing the actual outcome of the execution of that code.

Eventually you'll have millions of lines of code, and within those millions of lines of code there will be a bug. It's no different than writing a legal contract in English. In both cases you can only do your best to make sure there is no misunderstanding or undefined behavior, but there is always a possibility that at some point someone will find a flaw and exploit it.

On the other hand, you could add tests; i.e. list case examples of outcomes and ensure that the laws meet those tests. That would be particularly helpful in capturing where new laws or changes to laws may create loopholes in other laws. As you say, code can have bugs; test code too; but at least this enforces a more rigorous syntax and saves a fortune in having lawyers debate the meaning of the language used.

Testing? With respect to what requirements?

Instead of encoding laws in a programming language, they could encode the test cases in a natural language. List a bunch of specific scenarios and be explicit about how the law should be interpreted for them. Every time a judge makes a ruling on an uncovered scenario it gets added to the list. This would take about 90% of the work out of being a lawyer and would make the legal system much more accessible.

Instead of encoding laws in a programming language, they could encode the test cases in a natural language. List a bunch of specific scenarios and be explicit about how the law should be interpreted for them. Every time a judge makes a ruling on an uncovered scenario it gets added to the list.

Isn't that how common law already works?

I think that was the joke, but I'm not 100% sure....

Reminds me of https://twitter.com/paulg/status/802141209078759424

The tests are the lawsuits.

This is how some uniform laws are written. For example, each section of the Uniform Commercial Code (UCC) is followed by commentary, often including example situations. States are encouraged by the UCC committee to incorporate the commentary as part of the official statutes. That makes them binding. Where states choose not to incorporate the commentary, judges usually treat them as strongly persuasive (if non-binding) authority.

The nice thing about the code commentary is that it's easier to append or modify the commentary than a code provision itself. When a provision is changed all the case law is effectively discarded, creating tremendous uncertainty. But changing the commentary is much less likely to break backward compatibility, so to speak.

Of course, the UCC is much more carefully written and reviewed than ad hoc state legislation. The commentary is a little like gilding the lily, relatively speaking.

This is just as easy to write in English without ambiguity:

the (i) canning, (ii) processing, (iii) preserving, (iv) freezing, (v) drying, (vi) marketing, (vii) storing, (viii) packing for shipment or (ix) distribution of: .....

Using a programming language would avoid the scenario where there is more than one valid way to parse the same text. Usually, that's not the problem, though. Often times, the problem is that the correct parse is not the one people intended. Programming languages suffer from that too: http://lucumr.pocoo.org/2011/2/6/automatic-semicolon-inserti.... And even more commonly, the problem is ambiguity in semantics rather than ambiguity in syntax. What is a "fish product," for example?

fish product:

1. the result of multiplying fishes, as done by Jesus

2. a type of multiplication indicated by the fish symbol (see also: dot product, cross product)

3. a product intended for use by fish

4. the yearly economic value produced by fish (see also: gross national product)

Or a product made from fish (you may have a category, sales of fish and fish products). Or a product made by the fishes themselves, like corals are a product of marine life more generally.

Lojban-style formal legalese could work, but then it would threaten the legitimacy of contracts, since you'd need to understand law-specific distinctions in language to have a meeting of the minds.

Ah yes, a classic. I always love coders who are so naive they think computers are deterministic and code can be perfected.

How much perfect code have you come across in your life?

Once I figure out how to get my coworkers to stop checking in code with basic logic errors in it, I'll get right on that.

Coworkers...right.

If all you have is a compiler, everything looks like a line of code.

And we never ever write bugs, right?

The law is not a programming language. Believing so is a common misconception amongst engineers, but representing it as such is likely (as I have said in this forum before) to lead to disappointment, frustration, anger, needless bickering, extended conflict, and vexatiously long, hard to read, and mostly unenforceable contracts.

The thing I don't understand is, if we take the last two elements in the list to be a compound, shouldn't there still be a conjunction before them? If I say you can choose between "French toast, cereal and bacon and eggs" that is very different from saying "French toast, cereal, bacon and eggs" regardless of whether the Oxford comma is used.

The fact that this law doesn't have a second conjunction should be definitive in showing how it was meant to be interpreted.

Yeah, the NYT article doesn't address the argument regarding asyndeton, which is the omission of a conjunction at the end of a list. See the Volokh Conspiracy article for a discussion of this.

What they should have done is write "packing for distribution or distribution of". They forgot they were writing a law, not a book, and that clarity is more important than aesthetics. As it is, the sentence contains one more ambiguity, which is whether there's a distinction between shipment and distribution.

How does the headline imply it was a typo made by the company? I did not get that impression at all.

I think most grammar nerds who know what an "Oxford comma" is would know that it's optional, and the kind of thing that can inadvertently change the meaning of a sentence. That's how I interpreted the headline, not that a typo was made. IMO the headline did a good job of condensing the issue into something I might be interested in reading without being misleading.

t. Anti-Oxford-Comma lobbyist

Reply on news.ycombinator.com