From Lawyer to Programmer • Hacker News Board

Re: From Lawyer to Programmer

#41

Post by sthu11182 » Tue, Apr 02, 2013, 8:46 PM UTC

fatman wrote: post #36

MWil wrote: post #34

Earlier quoted context omitted.

See, I found Orin Kerr's piece to be incredibly uninformed (as to the specifics of the case) because he literally wrote it by taking the complaint at full face value - this was despite the entire controversy being about whether there were facts to support allegations that Aaron was trespassing, broke and entered, stole property, etc... but that's another topic, it was as you said at least more informed than the avera…

Latex for briefs? Ah, the idealism of youth. (I was going to revolutionize legal research through artificial intelligence) Most lawyers don't have the time, and almost every court I practiced in had rules specifying a utilitarian uniformity that made fancy formatting superfluous.

I would agree. I think using Latex for a brief is likely to get a deputy clerk sending you a notice. District Courts will have local rules on formatting (with California having the oddest one I have seen yet).

Re: From Lawyer to Programmer

#42

Post by gamblor956 » Tue, Apr 02, 2013, 9:12 PM UTC

geebee wrote: post #40

jacques_chester wrote: post #16

Earlier quoted context omitted.

> The "Law School changes how you think" line seems to be a popular one, but I'm not sure I buy the premise that it's inherently different. I've done both. Law teaches how to bring rigour to fuzziness. In software we can set boundaries and push the fuzziness back into the problem domain. Lawyers can't do that, they must address the world as it is. Let me explain what I mean. Suppose you use constants with values for…

I apologize in advance for what will be at least a partially incorrect comment. But don't lawyers deal with this fuzziness to some extent by putting the question to a jury? For instance, suppose we were writing a software application to decide when to shut down a machine because it got "too hot". We could go ahead and assign a specific temperature, or perhaps set up an equation with a few different readings. Now supp…

You would never have such litigation in the first place--there is no such tort or legal concept of "too hot".

On the other hand, if the player were to sue for negligence, then the question of whether it was "too hot" is a factual question that the jury would decide, after the lawyers present evidence for their preferred answer (and possibly evidence against the undesired answer).

The jury's finding would be a finding of "fact" as to whether it was "too hot" would apply only to that case, because their finding would necessarily depend on the specific facts of that case. Juries cannot make findings of "law", which are general principles/rules that can be applied to other cases.

Re: From Lawyer to Programmer

#43

Post by jacques_chester » Tue, Apr 02, 2013, 11:56 PM UTC

geebee wrote: post #40

jacques_chester wrote: post #16

Earlier quoted context omitted.

> The "Law School changes how you think" line seems to be a popular one, but I'm not sure I buy the premise that it's inherently different. I've done both. Law teaches how to bring rigour to fuzziness. In software we can set boundaries and push the fuzziness back into the problem domain. Lawyers can't do that, they must address the world as it is. Let me explain what I mean. Suppose you use constants with values for…

I apologize in advance for what will be at least a partially incorrect comment. But don't lawyers deal with this fuzziness to some extent by putting the question to a jury? For instance, suppose we were writing a software application to decide when to shut down a machine because it got "too hot". We could go ahead and assign a specific temperature, or perhaps set up an equation with a few different readings. Now supp…

> Would the lawyer define "too hot", or would the jury?

The jury.

> the legal system would treat the jury's definition almost as definitively as a temperature reading input into an algorithm, right?

For this case, yes. For all time, no. The fuzzy set of "too hot" would become the legal precedent (the stare decisis). The actual temperature would remain a question of fact and not law.

If you read up on how fuzzy logic is applied in control systems, you'll see that there's always steps to take non-fuzzy inputs and "fuzzify" them before performing the fuzzy logic itself. Afterwards you de-fuzzify to get a crisp output.

Courts work very much like that: the law retains fuzziness because no crisply algorithmic system can encompass the total complexity of the human world. That's how equity arose ... which is a law history lesson for another day.

Re: From Lawyer to Programmer

#44

Post by jacques_chester » Wed, Apr 03, 2013, 12:00 AM UTC

randomdata wrote: post #39

RyanMcGreal wrote: post #32

Earlier quoted context omitted.

Unit tests are merely approximations of what challenges you can imagine your application will need to face. An analogy can be drawn to the body of precedent in case law.

Precedent only deals with regression, which is also useful to document in code, but should not be your only source of documentation. The purpose of testing, though oft missed due to the name we have given it, is to document your code. The tests explain intent, usage, etc. that can often not be conveyed by the code alone. Verification that the documentation does what it claims comes as an added bonus, of course, and i…

Law is like code. Documentation is nice. For law it's widely available. But all that counts is the law. Well-written documentation is not a substitute and a court will not give you leeway if you were mislead by mistaken documentation.

In common law countries, the entire process of law is actually a black box functional test. And again: that's the only test that counts. Everything else might be wrong.