[net.unix] Bug fixing and Program Size

hull@hao.UUCP (Howard Hull) (12/30/84)

Dick Dunn @opus writes:
>[Interesting side-side issue:  You may have heard the quip that "Every
>program has at least one bug and can be shortened by at least one
                                  ??? ?? ^^^^^^^^^
>instruction"--from which, by induction, one can deduce that every program
>can be reduced to one instruction which doesn't work.  IEFBR14, if written
>as the obvious, single-instruction program "  BR 14", does NOT work.

I really like this!  Where did you hear it?  Only trouble is, it conflicts
with my experience.  Usually, when I find a bug,

	1.  Both decreases and increases in instruction count are likely
	    by some number, the average being 2.71828182845904523536
	    The implication is that to avoid bugs, every program to do a
	    function must be written in every possible way.  To be absolutely
	    sure that you have the solution in the bag, you must write a
	    program to do everything there is to do, by writing a set of
	    programs to do each thing.  Then all of these programs must work
	    together.
	    The probability that they will do this is given by 1/(n factorial)
	    in each case, where n is the number of ways to do each particular
	    task.  For some of you, the number of tasks, t, approaches infinity.
	    The result will inescapably include both of the following:

		   needed functions		 unnecessary functions
		that have been omitted		that have been included

	    Now then, if all of the above are properly combined, you have:

				UNITY (There is in each case, after all, always
			   t 	        only one *right* way to do everything!)
	    The Result = Sigma  _______________________________________
			  n=0                   (n!)

	2.  The bug will be in a real-time program running under one of
	    the Unix clones adapted for the purpose.  The change in the
	    program length will wreck something else, either spatially
	    or temporally.

	3.  Because the numeric mentioned under [1.] above is greater than
	    unity, and is also greater than the binary base, the average
	    (program, data) length will grow (perhaps stochastically) faster
	    than its intellegent content - in a very familiar way - the number
	    of bits of address will crawl over the edge of any imaginable page
	    size definition in a vernier fashion as the program is developed.

	4.  As a result of bug fixes, a program has some random probability
	    of either vanishing completely, or of consuming the entire storage
	    capacity of the machine.  Which way it will go depends mostly on
	    the rounding algorithm used in the (undocumented) arithmetic
	    subroutines that came with the software, and the (erroneously
	    documented) algorithm the mainframe manufacture used for the
	    determination of which instructions will set, clear, or not
	    molest the carry bit.					:-)

            {ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull