Re: Software landmines (loops)

[mfinney@lynchburg.net]

In <35F70F41.67AC4347@earthlink.net>, Charles Hixson <charleshixsn@earthlink.net> writes:

>The problem is that with the limited range of structures comes a limited
>range of errors that can occur.  The se/se school is limiting a
>particular set of errors:  If you use their approach you WILL NOT make
>the errors that they have excluded.  On the other hand, advocates of,
>e.g., early returns, feel that by testing for errors early you can
>remove complications from the code, and thus remove a DIFFERENT source
>of errors.  The two are incompatible.  You can choose which you consider
>more important, but you only get to pick one.

The use of non se-se control structures to match the problem's "structure"
is really an important concept.

The use se-se did originate to reduce the number of errors, and as a first
attempt, was a very good thing.  The problem is that the first attempt at
anything is almost never the "correct" answer.

I believe that what we need to do is to study many, many programs and
find out what the "natural" structure of the programs are (in the small
scale).  Then we need to design control structures to match each of the
patterns that we find.  There are, of course, an infinite number of patterns
but we can limit ourselves to those which we find repeated on a somewhat
regular basis.

Many authors have looked at control structure variations such as the n 1/2
loop problem.  There are others such as exit from a binary tree insert which
has three different exit conditions with different actions occuring at each
exit (add left, found it, add right).  Knuth introduced situation labels to
assist with problems like this.

I have made a study of many control structures for years as a hobby and
virtually all of them are tree-structured, but they are not structured.  It
is clear that many people feel that the original se-se structures are just
too limiting, but they still want "structure".  When considering control
structure improvements, the right place to put the line seems to be tree-
structured instead of structured.  It gives just the right amount of
flexability and still maintains a regular program structure.

As far as "provability" is concerned, any of the "regular" control structures
can be constructed from the se-se control structures with the possible
addition of extra flags and tests.  That means that if se-se is provable
then these additional control structures are also provable -- and probably
in a much more direct manner.  In a different post, I have a minimum set
of control structures from which all tree-structured code can be built.  I'm
sure that nice properties for those can be found which assist proving
program correctness.

However, proving program correctness is kind of a moot point at the
moment because nobody can do it for any kind of a sizeable program.
I have hopes that the advances in theorem proving combined with OO
built using preconditions/invariants/postconditions from the ground up
could give major advances in proving program correctness.  The use of
program transformations which start with a predicate and then use
transformations which provably retain correctness to convert the
predicate, step by step, to an executable program can also assist in
that area.  I feel that combining all of these things together (better
control structures, OO grounded with invariants and program
transformations) can result in large programs which are provably
correct -- but not by hand.  As always, the tedious details are where
computers are useful.

Even Robert agrees that the use of a particular se-se control structure
should be based on costs and benefits.  Of course, the major problem
with that is that nobody knows what the costs and benefits really are
when compared to slight variations such as exit from the middle of a
loop.  We all believe that there are significant benefits from the use
of structured programming compared to the original unstructured
programming.  But there is no evidence that I have seen that the 
original structured programming is better or even as good as some of
the "improvements" in control structures that have been invented over
the last 20 years or so.  I personally believe that these control structures
*do* improve things by reducing errors both in coding and in maintenance
because they improve the programmer's ability to reason about the
program in a "natural" manner.  However, that is just my opinion and is
only backed up by my experience (which is around 28 years or so, perhaps
not quite as long as Robert's, but hopefully just as good <g>).

I do know that I apply the principles above as much as possible (and would
do a lot more if I had the computer support I need) and the results have
been very good -- but perhaps the results would be just as good anyway.
There you get the question of the programmer vs the process.


Michael Lee Finney