Reading computer code, it's not a floor wax or a dessert topping!

I agree that contract law is an area where particular precision and forethought is needed, but I don’t see how requiring lawyers to take coding would be of any assistance, compared to the training we already get. To put it another way, if people think lawyers should be required to take coding classes, would you also accept that computer science students should be required to take a couple of classes in legal drafting?

Just because they’re similar skills doesn’t mean cross-discipline studies will be a significant improvement.

Is there a missing “not” somewhere in the first sentence?

I fail to see how coding skills would be of any advantage in a trial. Generally the law is only part of an trial. A big part of any trial is proving your case, or disproving/casting doubt on the other party’s case. That often turns on what documents are available, and what witnesses are available.

If you’ve got witnesses with conflicting accounts of what happened, how do you code for “You should accept Barb’s version of events, rather than Bill’s version, because Barb is more believable in the way she gave her testimony than Bill was”? Or, how do you code for “Even if you accept Carl’s account as trustworthy, you should take into account that he was across the street from the events, so he may not have had the best view, compared to Barb who was on the same sidewalk”?

How do you code for “The relevant documents were lost in a fire, so you shouldn’t draw any inferences from my client’s inability to produce them”, Especially if the other side counters with “You should ask yourself how the fire at the plaintiff’s building started, by coincidence in the room where the key documents were stored”?

And there can be uncertainties in the law. What if the particular provision in question has not been interpreted by any court in your province, but similar provisions have been interpreted in province A and province B, and the courts of A reached a different interpretation than the courts in B? How do you code for “We submit the Court should follow the interpretation of the courts of A over the courts of B, for the following reasons”?

Yes I did leave out a not. My point wasn’t so much about lawyers learning to code, but comparing the skills, and yes, both lawyers and engineers would benefit from some exposure to the others disciplines.

As for trial lawyers, I was only trying to point out that at times a trial lawyer can benefit from a well structured presentation, not that there was a significant overlap with coding skills, or that it came up that often in some clearly distinct way.

But I did point out what so many lawyers are experts in is human language and human nature. Those skills are entirely different and far more of what’s needed in the organization of a trial and so many other aspects of the legal profession. Those are skills too often lacking in software developers.

But mainly, lawyers should get more technology exposure so they won’t keep asking their friends to fix their PCs.

To me, it’s a bit like a road trip.

You have a start point and end destination (hopefully).

You need to bring some things from the start. Or at least get somethings quickly (data).

Then, along the way, you may need gas, or have problems. You can’t continue without fixing that.

And, you might have detours, bad weather, accidents and so on. You may find out you have to pick up a great aunt that is not yet ready to leave and wants to visit her cousin. This is news to you.

Hopefully, the people that you are traveling with to the same destination didn’t forget some critical item that you have to go back for.

And here’s an example. This summer we were figuring out the impact of Covid on a conference. Someone mentioned that times like these showed if the lawyers writing the contract covered all the bases, since the clauses we usually skip over suddenly became very important.

Logic is vital in law, see the LSATs. The advantage of programming versus other means of teaching logic is that mistakes can’t be ignored, but come back and slap you in the face. Programmers are not better at covering all the cases because we’re better critical thinkers, but because we always have to deal with the consequences of leaving cases out.

Before he passed away, my father-in-law (who taught Computer Science at university before he retired, including myself both before and after I married his daughter) was writing a language and compiler that would be provably correct - he had done some work with the Haskell community, and wanted to merge the syntactic ease of something like Modula-2 (which he had worked on the standard library for) with the robustness of a purely functional language like Haskell.

He never completed the language, though the design and library was fairly complete. But the idea was that all the boundary conditions were baked into the function definition (called a contract) so a function would error if the function was called with parameters that caused an invalid result. Because of this design feature, you can develop formal mathematical proofs for programs expressed in the language that ensure that invalid behaviour cannot occur.

It was a shame he didn’t get any further, and I certainly didn’t have the chops to pick up the development.

Even that’s not the hardest part in my opinion - Understanding your computer environment where the code actually runs is the hardest, and (as a non-programmer who sometimes wrote ad hoc code) I think that’s really what separates good programmers from bad ones like me. It was infuriating and complicated that I could write a program with subroutines and well-named variables and then couldn’t get it to actually run because I was in the wrong environment or the libraries or packages or whatever weren’t accessible or I didn’t catalog it properly. I never got the hang of the underlying computer architecture; someone’s always set up my computer for me and said “now if you write some code you can run it.” I think knowing what’s behind that is the hardest aspect.

No, those things are really fairly easily learned. I agree with @CookingWithGas about requirements analysis and design as the hardest part of a large software development project. Although for applications development, I’d regard requirements analysis as more of a business analyst domain than a technical one in most cases. But design is the hardest technical part. For a major development project, it requires the ability to conceptualize the big problem as a set of generalized abstractions that are compartmentalized and independent, and connected only by well-structured protocols. It makes all the difference between a product that is reliable and maintainable, and that can evolve with changing needs and implementation platforms, versus an unholy mess that can’t even be maintained properly. It makes all the difference between success and failure.

For a long time, I’ve thought of partitioning as one of the fundamental hard problems of Comp Sci.

Reminds me of what I said in another thread. The hardest part about marking math tests is trying to get into the students’ heads to figure out where they went wrong so as to assign them reasonable part marks. But it suggests that while math ability might not correlate well, the ability to read math papers might. I can affirm that I am better at actually doing math than at reading papers (occasionally even my own long ago papers).

Really, the problem is much more fundamental. Contract law and similar things would benefit from being written in a formal language instead of English. Programming languages are one type of formal language; the notation of set theory is another. Contract law would probably need its own to handle its special needs.

There’s a famous case which cost a city $5M due to a missing Oxford comma. This couldn’t happen with a formal language. The contract would fail the verifier and not be accepted. And if there were some mistake that still passed verification, the meaning would nevertheless be totally unambiguous and not need to go to court. Which might be part of the reason lawyers haven’t created a formal language yet…

If anything, the trend nowadays seems to be away from specialized legalese in areas like consumer contracts or agreements and more towards common everyday language that the consumer can understand. For more formal contract purposes, existing legal terminology seems to be adequate. The last thing we need, IMHO, is some cryptic formal notation.

In any case, I think @Northern_Piper is right that learning to code wouldn’t be of any assistance in writing contracts, largely for the reason I already mentioned – that natural languages and the formal languages of programming have virtually no relationship, to the point that it’s rather unfortunate that programming notations are called “languages” at all. Strictly speaking, they are, possessing as they do a syntax and a grammar, as someone pointed out, but it does leave a misleading impression. Legal language, OTOH, is really just a slightly specialized form of English (or whatever language it derives from) and is absolutely, in every way, a natural language.

The current situation seems to be the worst of all worlds, though. It’s already cryptic and takes years of education to understand. And yet it still manages to be ambiguous and lead to lengthy fights about interpretation. A formal notation could be both clearer and more precise.

The consumer-facing stuff is a different matter, certainly. Really, EULAs should be thrown out completely.

And the news story about that comma even includes a quote

The same could be said for the language of any constitution, the wording of any law, the text of any instruction manual. I think it’s a silly quote because it’s trivially true only in the very narrow sense that all these things I just mentioned have to be accurately written. But “accuracy” in natural language generally means something entirely different than accuracy in the notation of a computer program (though this specific case was a rare exception), because as I keep pointing out, natural language bears virtually no resemblance to the formalisms of computer code. “Accuracy” in natural language simply means care to avoid ambiguity or the possibility of misinterpretation. The things I just mentioned are written by people, for people, and so are written in natural language with all of its naturally evolved rules and semantics. Any comparison to code is entirely specious and meaningless.

There have been many attempts to formalize specifications in a language - best I can tell is that they all have failed. They would be great in that you could prove that an implementation meets the specifications, but ensuring that the specification is complete would be tricky. And formal specifications have bugs also.

That’s begging the question. The question I raised is whether some of these things would be better written in the language of computer programs, math, or some other formalism in the first place.

The lawsuit above hinged on defining a set of people for whom overtime pay did not apply. But the definition was a mess even aside from that missing comma. One can guess what they meant, but one shouldn’t have to guess. Even adding a simple but unambiguous way to declare sets in a contract would be a help. That’s something that’s very easy in programming and math.

At any rate, this is somewhat divergent from the OP, but I bring it up because the kind of thinking needed to learn a programming language is also the kind of thinking that might lead to advancements in how law is conducted. The majority of what I learned in school doesn’t directly relate to anything I do daily. But it broadened my mind in ways that do help me day to day.

So while yes, computer languages are not equivalent to spoken languages, they can be replacements in some cases, and the more people that are at least capable of thinking in the more formal way required by programming, the better.

Could you be more explicit here? I’m not talking about trying to formalize English, or legal English. I’m talking about adding features to the language of contracts to reduce ambiguity.

Here is a Wiki page about it. There has been a ton of work in this area. (I’m not sure of where it stands, as I got more into hardware I kind of gave up even reading CS papers.)
You obviously can’t prove a program correct without a formal specification of what correctness is.
When I was in grad school I got to see Dijkstra give a talk about program correctness proofs. My conclusion was that proving code correct would be easy if we were all as smart as Dijkstra. Alas, none of us are that smart.

I think I’d disagree with that. Mathematical proofs don’t have a formal specification. At some level, it is a human endeavor. It’s just that reasoning in a high-level, abstract way is more reliable than not. And having a specialized, formal language is better than an informal one. Automated proof checkers do exist, but they’re pretty limited, and most are checked by humans.

That said, I’m not talking here about proving a contract to be correct. Rather, having a language that allows expressing common constructs like set membership in an unambiguous way, and perhaps allow evaluating the validity of a contract (different from correctness).

In a mathematical proof the theorem to be proved is precisely specified - formally specified in fact. That corresponds to the specification of what makes a program correct. Practically speaking the process of doing the proof is a human endeavor, but automating it should be feasible. That is a lot easier than automating the creation of a formal specification.

I agree that this would be a great thing. I’m saying that having a formal language for contracts is not likely to solve all the problems. In fact, as I had suspected, work has been done on this - mostly for formally analyzing contracts though. Here is one example. (PDF). I searched for “formal logical specification of legal contracts”.
But how would you ensure that any contract get the response to the current pandemic right? (This was of great importance to my conference.)
A big problem in learning systems now is that no one knows how they came up with their results. Do you want contracts specified in such complexity that no person can understand them?
Especially since we know that bias can easily be introduced into learning systems. I’d hate for bias to be part of an automated system that understands contracts and resolves disputes. It could happen. In fact, it will happen if we go that way.