Bugs and Loopholes (Re: The State of Python)

[Peter Hansen]

Has anybody ever noticed how incredibly like software most legalese is?
The phrase "lawyers many times introduce more holes than they plug"
describes exactly the situation where poorly written code (i.e. code with
loopholes) is patched repeatedly by other programmers who in the process
create even more bugs.

Loophole == bug

Law == code

Laywer == programmer (no insult to either lawyers or programmers intended
:-)

If you look at a given law, for example, you find content which would
benefit from refactoring in a big way.  Structures which should be
rewritten in a general way (i.e. Class/Algorithm), then applied to specific
instances.  I've seen legalese that ought to have a few macros defined up
front which are then substituted in the appropriate places in the code
(oops, I mean text) instead of massive parallel structures with huge
redundancies.  Skimming a copy of the Canadian Income Tax Act I see
structures far better suited to description using object-oriented design,
control structures, switch statements, variables, and subroutines than
English text.

I figure much of the design of laws (the structure part, anyway) could best
be done by people with training in the latest software design and coding
techniques than by people who, I assume, are using a design methodology and
"coding style" which is probably over 100 years old!

ObiJohn wrote:

> There is no "magic" in making a license. Indeed the Python 1.5.2 is a
> valid form of license. What the CNRI lawyers mean is that there are too
> many holes in it for a lawyer's taste. Lawyers *hate* short, consise
> contracts and licenses simply because it is so easy to make them appear
> to contain loopholes, even if the author did not intend it. Efforts to
> close those loopholes results in licenses like the GPL. Unfortunately,
> lawyers many times introduce more holes than they plug, and other
> lawyers step in to plug those... just look at the GPL/QT wrangling.
>
> Is there a simple answer? Not when the lawyers are involed! I would be
> greatly surprised if they were satisfied in 2 days.
>
> -- John Stoneham, Beaumont, Texas
> Life is too short: Program with Python!

--
-------------------------------------------
Peter Hansen, P.Eng.
Director of Software Engineering
Kaval Telecom Inc.
905-940-1400 x3491
phansen at kaval.com