Monday, March 7, 2016

My Ideal Platform: Cleaning up US Law

[Note: This is an alleghory about law. I didn't think the computer programming examples were too far out of reach. But even if you think the listing of BASIC source code looks scary, please don't be intimidated. Bleep over the code. There's important stuff down below. JMR20160310]

If you have ever been involved in large software projects, you will have heard the expression, "spaghetti code". The term is used to indicate that the code is unstructured, tangled, difficult to understand, difficult to modify, and difficult to prove correct. In other words, spaghetti code is not good code.

("Rat's nest" is another term used with similar meaning.)

The entry in wikipedia on the subject, as I write this, mentions GOTOs, exceptions, and threads of control. It shows an overly simplified example:

10 i = 0
20 i = i + 1
30 PRINT i; " squared = "; i * i
40 IF i >= 10 THEN GOTO 60
50 GOTO 20
60 PRINT "Program Completed."
70 END

This is compared to the slightly more structured-looking

110 FOR i = 1 TO 10
120     PRINT i; " squared = "; i * i
130 NEXT i
140 PRINT "Program Completed."
150 END

The latter example (lines 110 - 150) is a bit more clear (especially if you are familiar with this use of the word, "for" in the English language).

But the former example (lines 10 - 70) is not really unstructured. The GOTOs are merely being used to construct the execution paths of a counted loop, whereas, in the latter (lines 110 - 150), the FOR ... NEXT explicit counted loop is used. The layout of the former code pretty much shows the structure of the loop. And the code is short and clear.

Some early dialects of BASIC had no multi-line loops. When you write structured code for such dialects, it basically looks like lines 10 - 70, but with more stuff between the GOTO lines.

So this example is a little easy to misinterpret. It doesn't really demonstrate the primary qualities of spaghetti code.

We need a better example.

In the following, I'll use a misfeature that was originally intended (ironically) to help improve code structure, the computed GOTO (line 300), to help slightly tangle the code:

200 e = 0
210 GOTO 300
220 PRINT i; " squared = "; i * i
230 GOTO 300
260 REMARK Remember to set e before you start! 
300 ON e GOTO 310,330
310 i = 0 
320 e = 1 
330 IF i < 10 THEN i = i + 1 ELSE GOTO 350
340 GOTO 220
350 PRINT "Program Completed."
360 END 

Yes, I deliberately contrived this example. And maybe my use of the computed GOTO was specious. Line 300 could have read
 300 IF e = 0 GOTO 310 ELSE GOTO 330
for the same effect. But you can see how the code is beginning to develop spaghetti structure. The code jumps around. That is, there are branches (GOTOs) and branch targets (the numbered lines) that you don't really know reasons for unless you sit and think through the code.

[I decided to check the code with a real BASIC interpreter, and I posted the results in my Programming is Fun blog. And now we are done with talking specifically about computer program source code. JMR20160310]

While you can read the program effect of each line of code, you are not sure of the real meaning, the semantic intent, of each line.

The question you should be asking is, "Why did this end up this way?"
Usually, software engineers don't intentionally write code like this. Sometimes we do it for fun and recreation. I've done it here to demonstrate a mild form of the junping around that we call spaghetti.

Some engineers (maybe engineers who are not all that confident of their own ability to keep a job) do actually write spaghetti code intentionally.

How this kind of code usually gets written, however, is that code just tends to grow. You start with something simple, then you find it doesn't work everywhere you want to use it, so you "fix it". Sometimes you want to add useful features, so you fix it up a bit.

That means adding code.

It also should mean removing code and re-structuring code, but we always have something else we want to be doing. And we usually have lots of other things our managers want us to be doing, because lines of code disappearing or just moving around doesn't seem to be evidence of productive work.

First, some lines will get re-used. Therefore, the meanings of those lines changes, because of the re-use.

Then, in order to support the changes in meanings, code is added here and there, and spaghetti-like structure gets added to the code.

It's like a shelf in your workshop that you quit using, then you start using it for something else. You didn't plan on it holding more than some small flower pots, but now it's holding a bunch of books, and you sometimes look at the nails and the warping planks and wonder how it's holding up. Someday it's gonna sag and fall.

Now, it's not so much where the code was coming from and where it is going to when it hits line 330, it's what the meaning of line 330 is in the context of where it came from and where it is going.

(I could offer more examples via include files and conditional compilation and macro definitions in the C language, but I hope this is enough.)

The spaghetti is semantic spaghetti more than flow of control spaghetti. You are following a thread of thought in the code, and suddenly there is stuff there that breaks the thread of thought that you thought you were following. And you have to go looking somewhere else in the code. Sometimes you have to spend hours just looking for where you should look.

What does this have to do with a campaign platform?
US law has a lot of semantic spaghetti in it. Laws that were written years ago are repurposed for things they were never originally intended for.

So the laws are "fixed" by adding snippets of code. Sometimes you put a note in that a particular word should be read with a special meaning in a particular section of the code. Sometimes you put in a note that a particular section has been basically repealed and replaced by something else, with notes about where to find that something else.

So you often have to jump through a lot of addenda to read and understand the current version.

Even in the best of cases, in order to write laws concisely, specialized definitions are use, and you have to refer to the specialized definitions or find yourself misinterpreting the laws. But the longer the code sits around gathering cruft, the more of those specialize definitions appear.

One more egregious factor in spaghetti law, there are usually "riders" on laws, things leftover from the bargaining process that add to the complexity of the law.

A law is passed for one purpose, but, in bargaining to get the law passed, agreements are made that have nothing to do, really, with the law. And those agreements are attached to the law, "riding" into the code on the backs of the irrelevant law. More addenda.

And would it surprise you to know that laws are often written using incorrect grammar and vocabulary? Too many lawyers never really got a good grip on the basics of language.

I have often thought that a "Doctor of Law" degree should require a minor in both computer science and linguistics -- linguistics because lawyers who can't read and write English can't make good law in English, and computer science because lawyers should be required to understand the processes of definition and implementation of code.

Code for humans is a bit more malleable than code for machines, but it's still code.

The end result is that laws, as they exist on the books, actually end up with a lot of effects different from the advertised intent.

The US law (US Code, they call it) needs to be cleaned up.

The president cannot void laws that already exist, but he can use his power of veto to send badly written law back to Congress, with his reasoning, and make them either fix the laws or override his veto, if they want the bad laws passed.

One platform I would like to see candidates run on is a platform of never allowing bills from Congress that he couldn't read and understand to become law, to veto such laws and send them back with the reasons.

That's what the Constitution says he is supposed to do. If he doesn't approve it, he is supposed to send it back, with notice of disapproval, and with his reasons. Take a look at Article I section 7.

Poorly constructed law, including the existence of riders and such, should be plenty of reason to send the law back. Almost automatic reason.

And a willingness to commit to do so on his platform would indicate he understands at least part of the Constitutional definition of the Office of President that he aspires to.

No comments:

Post a Comment