As I’ve mentioned before, there are a lot of analogies between programming and legal work.
I’m working on an upcoming post to explain a specific application of a legal concept. Unfortunately, I think this is one of those few concepts where there is not a ready programming analogy. I’d love for someone to prove me wrong, since the programming side of my brain is slowly going to pot. Here goes:
In law, there is the concept of “rules” and “standards.” Basically, rules are precise- they allow a judge to simply look at the facts, apply the rule, and voila- you know whether the rule was violated. An example would be “The speed limit is 55.” If you’re driving 56, you’re in violation- even if, say, you’re speeding to the hospital with your pregnant wife. Alternately, if you’re driving 54 you’re fine- even if it is pouring rain. Rules are good because they are easy for the public to understand (no need to consult with a lawyer) and because their application (should be) very evenhanded, but good, fair rules are very hard (in many cases essentially impossible) to write.
A standard, on the other hand, is more vague- something like “The speed limit is whatever speed is safe to drive at under the circumstances.” This might not allow you to go 56 to the hospital, but would definitely not allow 54 in the rain. These are bad in some ways because they are trickier, case-by-case, hard to predict the outcome of beforehand, and involves judgment on the part of all parties, but (arguably) produces better outcomes a lot of the time- assuming you can trust the parties doing the judging, and you can put up with the cost of taking the time to make the decision.
So… for those of you who have lasted this long: are there analogies to this in software? The closest thing I can think of is strong typing vs. weak typing, but generally, since computers are incapable of dealing with standards, there aren’t many examples I can think of. Am I missing/forgetting something?
RFC2119
Sounds as if standards correspond to non-formal specification for programs. Doesn’t fit perfectly as specifications are to be implemented with programs (e.g. rules), but standards are not.
Algorithms vs. Heuristics is exactly what it sounds like. Algorithms come up with results every time, like rules. They are a finite set of steps taken in order to solve a problem or complete a task. Heuristics, on the other hand, are very much like “Leading spades” in a card game, a general rule to follow that may or may not result in a win or success, and these are like your legal standards.
I’m tempted to think about the “Be Lenient with what you accept, but strict in what you output” as well as the “compability” modes of various renderers ( most famously html ) but neither matches well in my opinion.
Floating point versus integer. You can check integers for equality, but you can only check floating point numbers for differences less than epsilon.
I also second the reference to RFC2119. Rules correspond to “MUST”, and standards correspond to “SHOULD”.
Standards aren’t quite right, but they are a heck of a lot closer than anything I had in mind- thanks! (I think it may be telling that every implementer of standards I’ve ever met says that the more rule-like the standard the better.)
JF: Heuristics don’t actually get written down in code, though, whereas in many cases in the law standards are in fact what is written in the code. Or to put it another way: in the code-law analogy, judges are compilers, and you’d never ask a compiler to compile a heuristic, whereas we ask judges to “compile” standards all the time. (They’re probably actually closer to interpreters, but you get my point hopefully ;)
I’d also second the SHOULD/MUST distinction. I’d also say that the concept should be fairly familiar from code review – there’s big gaps between code that runs and acceptable quality but these gaps arenall soft and male able ones.
How about nonmonotic logic? It doesn’t come from programming but logic is close enough.
http://plato.stanford.edu/entries/logic-nonmonotonic/
Code review is not quite right, because that’s a distinction between good and bad code. Whether good or bad, the compiler still interprets the code the same way. This is more fundamental than that- it’s closer in this sense to chosing a language; it sets out the parameters within which you then write the good or bad code.
[…] }); like_show('327851', 0); flag_show('327851'); Niger Luis Villa » Blog Posts looking for a programming analogy- if there is one one hour ago As I’ve mentioned before, there are a lot of analogies between programming […]
I have been struggling with legal-computer analogies for the past five years and the results are kind of mixed. The problem is that although I had believed in it first, there is really a difference between legal logic as you know (especially in the US law AFAIK). There are almost no really hard rules, and even “The speed limit is 55.” is more start of the discussion than its end (usually stakes in the speed limit are so low, that nobody spends enough money on lawyers on dealing with it, but I can immediately imagine some defenses how I would try to fight it if necessary).
You know as well as I do that when the client asks you “Will we win the case?” the honest answer is never Boolean. “If court accepts our defense, then we are more likely to prevail and win such and such amount of money, but …” and then there is a long explanation of what could happen.
For me, coding style guidelines come to mind.
The goal of most coding style guidelines is consistency and readability. For the most part, the consistency part can be spelled out as a set of hard and fast rules like brace style, tabs vs. spaces, whether to use upper or lower or camel case for identifiers, etc.
The readability part is harder to pin down. Some guidlines can sort of point the way, such as maximum line lengths, how many levels of indentation before you should consider breaking off a new function, how to name variables, when to add comments, etc. But there’s always a little wiggle room. It’s ultimately up to the author to decide what is the most readable way to express source code.
An equivalent is analyzed algorithms and ones that have not been analyzed. In ‘The Art of Computer Programming’ Donald Knuth analyzes many algorithms, proves their finality, scaling behavior with regard to memory use and execution time.
Rules are completely predictable algorithms: given the inputs, one knows the behavior of the algorithm. Standards are all other (and sadly, most) algorithms. There is very little software like a rule. Most code has many run-time dependencies that make the behavior hard to predict exactly.
In many situations, this is not a problem. But a lot of reasoning about software would be so much more reliable if more algorithms were analyzed in detail.
For desktop software the analogy is even stronger. You need many environment variables and files present to have a program execute well. In practice, software is like standards, not like rules.
Perhaps try the difference between specified behavior and undefined behavior? C and C++ don’t define what happens when you dereference NULL. In most programs and systems it’s just a crash. In some you can map page 0 such that dereferencing NULL “works”. And there is a somewhat reasonable point to doing this: I remember deliberately dereferencing NULL at one point during OS startup in the OS class I took, relying on the previously-set-up page tables to make the effect be the desired one. So you could see precisely defined behavior that is the bulk of the behavior as “rules”, and you could see undefined behavior at the edges being akin to the “standard”.
Matej: oh, any such analogy is tricky, prone to error, etc. But they can be useful if you give the right caveats. In this case I’m considering trying to explain the difference between GPL’s copyleft (a standard) and MPL’s copyleft (a rule) as well as other similar issues, so having some context could be useful.
Jeff: eeenteresting. Again, not quite on point, but may be useful for some parallel discussions that are a part of this (hypothetical) point. Thanks!
You have both types of “enforcement” for bugs. There are some bugs, e.g. syntax errors, that are obvious and are applied as rules. Then there are bugs whose existence is only discovered when a person uses the program and the output does not match her / his (valid) expectations.
What about fuzzy logic? (http://en.wikipedia.org/wiki/Fuzzy_logic )
Perhaps compiler errors vs warnings (or lint checks, or coding guidelines)? Not a perfect analogy, but close… Errors being the rule — doesn’t matter if you’re almost right, or if you’re running up against some arcane issue in C++. Warnings being the standard — sometimes they catch obvious mistakes, sometimes they’re annoying false alarms (under the constraints/assumptions of your code). But it takes some inspection to figure out the severity of the warning, and there are times when two programmers will disagree about the need for fixing a warning.
SELECT * FROM laws WHERE name = ‘rule’
SELECT * FROM laws WHERE name like ‘%standard%’
I may be under-qualified to have an opinion, but I think you were right on the mark with rules and standards as strong and weak typing.
A rule for floating-point addition would require the programmer to provide two floats as input.
A standard for floating-point addition would require two inputs that are convertible to floats. Two floats would always work, an integer and the string “3.14” might work, but (presumably) a Boolean and the string “My cat, Fluffy.” would never be accepted.
In fact, I think this works well on several levels. What can be cast (character to integer, integer to pointer, string to float, etc.) and how it is handled (does “int + string” convert the string to int and add or does it convert the int to string and concatenate?) depends on the language and runtime, just as judges might rule differently on the same standard and facts.
Luis: “Heuristics don’t actually get written down in code, though, whereas in many cases in the law standards are in fact what is written in the code.”
I guess heuristics are case law.
Like Matthew Barnes, I think that coding guidelines are a very good analogy. Most programmers know them, and they often have rules (“indent with 4 spaces”) as well as standards (“use short, concise and understandable names”, “wrap lines where it makes the code more readable”) side-by-side, which makes them good examples for illustrating the concept.
[…] http://tieguy.org/blog/2011/04/17/looking-for-a-programming-analogy-if-there-is-one/ @tieguy being !disturbing? I don't see harm. about 3 hours ago from web at South Berkeley, […]
Grammars for rules, protocols for standards.
There’s a likely analogy on the operational side of software, particularly SAAS, and in data mining (the number of times I’m seeing those two fields dovetail lately is getting spooky): we often differentiate between hard-coded limits (“rules”) and unexpected variations from a recent norm (closer to “standards”). For example, it’s the difference between alerting when available storage sinks below 10% (hard rule) and alerting when storage has decreased more than 5% over the moving average of recent times for longer than a few days. Or the difference between 100 people getting sick in a school versus a larger number than normal for that day of the week and month and season, relative to neighbouring schools, etc.
The reason the latter is a “standards” case in advanced situations is because you don’t program in what reasonable variations actually are. Rather, the code looks for things that don’t fit recent patterns and considers them anomalous. For the software author, it’s all rules (implementing a large and moderately tricky body of mathematical theory), but for the person viewing the results, it’s somewhat unpredictable but always within the bounds of “that’s an unusual variation, hence worth checking.”
Hmm.. adjusting the typing attempts might work, although I can see it both ways. Think of runtime- versus compile-time typing (dynamic vs. static). This is *not* weak versus strong typing (they are orthogonal).
With static typing, you know exactly the type the caller will be passing With dynamic typing, the contract is that the caller passes something satisfying an interface of some kind and the recipient works with that. The “standards” view of the latter is deciding how much of an interface to insist on when you’re writing a function that accepts something in a dynamically typed situation.
For example, one way to reduce a sufficiently old Python programmer to quivering anger is to specify “a file like object”, since it’s woefully badly defined how much is required to “file like.” The kids don’t have these stress levels, since they haven’t been around the block enough to have seen the problems in practice enough. Or consider passing a pointer to a function in C — you are loosely agreeing that the caller will only recast it to an appropriate type, if necessary, and not miscast and then overwrite some random field.
Malcolm: thanks for correcting the static/dynamic weak/strong mistake; that’s exactly correct.
(And thanks to everyone else for all the ideas; this has been a surprisingly fruitful bleg.)
Maybe a ‘standard’ is more like ‘performance’: in some circumstances we seek maximum performance (no more than 55mph!) but in other cases we allow performance to be less than optimal to all for other qualities (<>55mph in an emergency). So the analogy is less about a programming itself and more about the application of programming to particular problems.
How about:
Rules = the grammar and syntax of a language programming language. Break the rules and your program wont’ compile.
Standards = coding conventions. Break them and your code will compile and run, but it may have hidden problems and may be considered as inferior to code which does follow the conventions.
HTML5 vs XHTML error handling – one of them about strict application of rules, the other about making the best out of the data from the web server.
It’s the difference between Boolean logic and RFCs.
Boolean logic is a strict “if this condition is true, then do that”, whereas RFC standards have language like “must”, “shall”, “should”, that indicate varying levels of freedom implementors have when implementing the specification.
Rules are like imperative programming, where the program describes a set of steps that must be followed, and the outcome is defined only implicitly, as the result of following those steps.
Standards are like declarative programming (eg, HTML, SQL, regular expressions, Prolog) where the “program” describes the outcome you’re looking for, but don’t specify how to actually compute it.
[…] Syndicated 2011-04-17 16:43:47 from Luis Villa » Blog Posts […]
My suggestion is not strictly programming, but closely related: image formats
*Rules* are like palette based formats (PNG if you like): You introduce arbitrary distinctions (-> a color palette). When your rules become simple (-> images become small, old GIF style), your picture of reality becomes simplistic (-> black/white in the extreme case). Or you try to satisfy all cases (TIFF, lossless PNG), but then your rules get blown up and bulky.
*Standards* are like JPEG (lossy compression): If you capture reality the right way (-> wave quantization) and if your receiver interprets the standard appropriately (-> laws of human perception such as gestalt laws…), you can express complex concepts in a compact manner. However, if your recipient tries to interpret the standard by the letter (-> the image by the pixel), the original intent (-> source image) will be misrepresented/unrecognized.
You can view laws as a system of rules that attempts to optimize (in the mathematical sense) the overall benefit to society.
In an optimization program you’re generally trying to optimize an objective function (minimize deaths due to car accidents) by trying to reduce unnecessary slack in the system (your right to drive as fast as you can).
The complexity of the optimization program depends on the complexity of the situation being optimized coupled with the amount of slack you’re prepared to tolerate within the system (the JPEG/PNG example in another post is a special case of this). Normally the more efficient a system is, the less slack it has but also the less resilient it is.
As such a rule and a standard are simply two examples of optimization programs of varying complexity rather than properly separate concepts. Trying to classify laws into ‘rules’ and ‘standards’ might lead to entertaining discussions of edge cases, but probably has little use outside of that?
For example, in the UK proper signs must be in place for a speed limit to apply. This fact can be used to wiggle out of a speeding ticket even though the road is broadly understood by society and the authorities to have a certain speed limit. The simple rule has now suddenly developed a whole lot more sophistication and interpretation and, I’d guess, starts to look to look a lot more like standard within this new broader context.
Attempt 2:
If words and case references in the legal world are subroutine calls,
Rules are subroutines written in assembly; small optimized function, written in normal everyday language – in which, just like assembly code, you wouldn’t want to write too much law due to repetition and verbosity!
Standards are longer routines written in legal jargon (and therefore rest on a deep and wide stack of legal machinery). You need an understanding of the legal culture (framework design) and the libraries to interpret these pieces of code. Therefore interpretation is generally left to lawyers and judges.
Programming guidelines? “Never use goto”, “No more than 3 nested statements”, “No more than 72 characters per line”, etc. Good programmers implicitly add “…except when it makes the code worse”.
Dave.
It looks to me like the only difference between a legal rule and a legal standard is context: the former is mostly independent of context, while the latter depends on it more heavily. (Of course, it’s impossible to eliminate all context. That’s what makes general AI so difficult.) The reason it doesn’t map to anything unique in programming is that the distinction is too general. e.g. You could make an analogy where rules correspond to functions that take no arguments, and standards correspond to functions that take 1 or more arguments. But there are many more possibilities, some described in the comments above.
Slightly off-topic: it’s possible to put your examples into code, which clarifies a little what I’m talking about:
The Car Speed Rule:
if car.maxSpeed > 55:
govt.fine(car.driver, “$200”)
The Car Speed Standard:
if car.maxSpeed > road.getSafeSpeed(weather):
govt.fine(car.driver, “$200”)
Good question. Below are some possibilities, although I’m not sure any really hit the nail on the head.
1 – When to use a data structure v. how to use a data structure. The latter is more of a rule, when to use one is more of a standard (although rules sometimes guide those two).
2 – User experience design v. User interface programming. The former uses standards while the latter uses rules.
3 – Programming for desktop APIs v. programming for web APIs. The former definitely uses rules. I would love to say that web APIs are rules too, but often they seem more like standards (see IE6, IE7, etc…).
4 – I’ve studied neural nets a while back and I’m a bit rusty, but they can handle standards more than say a state machine.
[…] for a programming analogy- if there is … tieguy.org/blog/2011/04/17/looking-for-a-programming-analogy-i… Top links from the same […]
[…] The document has moved here. […]