using break <label> instead of goto <label>

[Rob Warnock]

+---------------
| People keep hoping for the magic panacea that will ensure automatic
| correctness of their programs...
+---------------

Quite so, Doug. Also see the current? issue of "Whole Earth Review",
on the theme of "Computer As Panacea: All Panaceas Turn To Poison".

+---------------
|                       ... The one idea that works, to think clearly
| and carefully, has not found much favor.
+---------------

There is a reason. It is painful to do so until one has been trained
(disciplined) enough so that the results of NOT doing so are more
painful than the thinking. The training takes a long time. It too
is painful. There are not many teachers/mentors/gurus/old-timers
around who can help us through the rough stages, and doing so on
one's own is not likely (though possible). The sage advice printed
in books pales against your bosses' demands for "More!" and "Now!".
It requires an exceptionally hospitable environment (such as being a
support staff member in a graduate or post-graduate research atmosphere).

I remember the first time I seriously tried to write a program that would
be "perfect", that is, to compile and execute correctly the first time
it was submitted to the system.  (I had gotten all excited reading Djikstra
or somebody, and had this wild hair about "zero defect" programming.) I was
just switching from MACRO-10 (the assembler) to BLISS-10 (which has no "goto")
for doing systems programming, and was writing a "stdio"-like I/O package.
(BLISS-36 now comes with "EZIO", but it didn't exist then.) The specification
was fairly simple. I wanted the program:

	MODULE TEST =
	BEGIN
	REQUIRE	IOX.REQ;	! These days we say "#include <stdio>"

	LOCAL	C;

	WHILE	(C = GETC()) NEQ IOX_EOF
	DO	PUTC(.C);

	END
	ELUDOM

to give the user a standard prompt (using SCAN/WILD, for you TOPS-10 folk),
accept a command string of

	*OFILE=IFILE1,IFILE2,...

and do "sort of the same as" the UNIX command "cat ifile1 ifile2 ... >ofile".

The exercise in fact succeeded, but it was *P*A*I*N*F*U*L*. (And I don't
just mean giving up the "goto"!) The only way I managed to do it was to
write the entire program on paper, in a notebook, saving all versions and
notes and scratchings, and REWRITING each module in a clean form for each
step of refinement or backup. (Yes, I had to back up a lot.) A couple of
times I started typing it in, but realized there were pieces missing, and
went back to the notebook. That was possibly the most painful part -- staying
away from the machine. But it paid off. When finally typed in (and printed
out BEFORE compiling and desk-checked and corrected), it compiled and ran.

I am sorry to say that many times in the years since I have allowed myself
to become seduced again by the very addictive nature of working "on line",
sometimes to the extent that I could not consider working if the computer
was "down" (even when what I had to do could be done on paper!). But sometimes
when the project was just too big for me to hold in my head or on the 25 lines
of the screen, or when I just HAD to get it done right and on time, I would
revert to the "primitive" methods of pencil and paper, of "design before code".

I feel I have learned several lessons:

#1: "Zero defect" development of software is possible, but it requires
    a severe discipline in how one works.

#2: Even for people who know #1, and who understand what it implies, it is
    never easy. Constant little temptations or pressures arise to try to
    shortcut the necessary steps. It never gets any easier. The whole
    environment must support the effort.

#3: Knowing #2, the only way we will do it is if we realize the cost of NOT
    doing it (bugs we'll never find, slipped schedules, cost overruns, and
    maintenance headaches).

#4: Most software development organizations ("Management") are not willing
    to face #3 (see any book on Quality Control), so since #2 is still true,
    "zero defects" becomes impossible, or at least unlikely. Even individuals
    who understand #1, #2, and #3 find difficulty in consistently applying
    their understanding on problems that seem "too small" or "not worth it"
    (i.e., we ignore the cost to ourselves in getting sloppy in our discipline).

#5: Both large organizations and individuals tend to severely underestimate
    the scope of tasks, thus reinforcing #4.

How does this concern net.lang.c? In my experience, C is "good enough"
as it is. The above considerations far outweigh the minor wrinkles the
net has seen discussed recently (e.g. how to initailize unions, "goto"
versus "break" versus "leave"). Yes, C can be tuned a bit, and people
would benefit from it, I suppose.

(I favor the "leave <labelled-block>", myself, but frankly I don't recall
having ever used a "goto" in C, for ANY purpose, so who am I to say?) 

But to some extent, such discussions of the effect of programming constructs
on program correctness are similar to discussing the effect of the color of
automobile dash panel indicators on traffic safety while driving 90 miles
an hour in the rain, with one hand on the wheel, drinking whiskey, with the
radio turned up to deafening, your headlights off, and no seatbelt.

(While the sarcasm of the previous sentence may be a bit heavy, consider
the New England pediatrician who completely gave up his medical practice
of many years and went to work lobbying for infant car seats. He had looked
up one day and discovered that preventible auto-accident injury killed more
of his young patients than ALL other causes COMBINED, including disease and
all non-auto accidents.)

+---------------
|                       ... The one idea that works, to think clearly
| and carefully, has not found much favor.
+---------------


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404