From daimi.lovers Thu Jan 30 12:51:50 1992 Newsgroups: daimi.lovers Path: daimi!zat From: zat@daimi.aau.dk (Thomas Marcus Basse Gj|rup) Subject: Cowboy Programming Message-ID: <1992Jan29.105519.2072@daimi.aau.dk> Keywords: Nondeterminism, Spaghetti Programming Sender: zat@daimi.aau.dk (Thomas Marcus Basse Gj|rup) Organization: DAIMI: Computer Science Department, Aarhus University, Denmark Distribution: daimi Date: Wed, 29 Jan 92 10:55:19 GMT Lines: 182 Aarhus Universitet CP-nr. 1 Matematisk Institut JW/TG/zat Datalogisk Afdeling Cowboy Programming - an analytic approach and its applications 1. Introduction. The aim of this paper is to develop a theory for a range of new, non- deterministic trouble-shooting techniques in larger programs and systems, called Cowboy Programming. The theory will to some extend be a formalization of commonly used but not easily comprehended routines in programming, all characterized by a high degree of irrationality and - often seen - frustration. 1.1. The principle of arbitrariness. In this section we shall examine the theoretical basis of most of the techniques and applications known (and widely used) in Cowboy Programming. Fact 1.1.1: x=2. To prove this basic property we shall first have to show the following lemma: Lemma 1.1.2: Assume x is a variable, i.e. x is a well-defined function on N', where N' will be defined in definition 1.1.3. Then the value of x will be reminding of and not too far from 2. It suffices to prove that there exists a language in which x can be assigned any value in N'. In the language Babbage (as described earlier in daimi.lovers), there is a construct x~=y that maps a value reminding of and not too far from y to the variable x. As any value in N' is reminding of and not too far from 2 - there exist a function f:N' -> 2, that is - and x cannot be undefined, the value of x will always be reminding of and not too far from 2. Definition 1.1.3: N'=N \ (C u L), where C are the numbers in N that eventually cause a core dump and L are the numbers in N that are so awkwardly long, that no one is going to feed them into any automata, finite or infinite. Note that C and L are not disjoint sets. Lemma 1.1.4: Assume x is a variable placed in the mid 50% of a large program (to be defined later) and its value is reminding of and not too far from y. Then this implies that x=y. We shall not show the proof of lemma 1.1.4., as last time it was conducted at the University of Du"sseldorf by the late Doctor Gerhard Schwarzschmidt, he was forced to eat the very piece of chalk with which he had conducted the proof, including the chalk on the blackboard, including the blackboard, by a raving crowd of mathematicians who saw their careers coming to an end if this controversial result should be known in public. We can now, using lemma 1.1.2 and lemma 1.1.4, state the important Theorem 1.1.5: The behaviour of any program including the variable x and relying on the value of x being something far from or not at all reminding of 2, may not be well-defined. Using a great deal of induction on both the variable x and the value 2, one may show that similar theorems are valid for almost all other variables and values in N', too. However, these results are not crucial for this theory, and so, ommited. We shall rely on the previous results no further than to that extent where we can deduce the non-existance of a partially ordered set of variables and programs with the following properties: 1. If the set of variables is not well-defined, the execution of the program will not be well defined. Thus the program won't work. 2. If the program itself is not well-defined, it won't work. 3. The program will work only if the program and the variables are well-defined. Which we can. The behaviour of programs will in the following section be characterized by the two properties correct and lousy?. The change of property will be called worse if it maps the property from correct to lousy?, and a change from lousy? to correct will be called great!. Otherwise the change will be called unimportant. We introduce an ordering < on changes in properties characterized by great! < great! < unimportant < unimportant < worse < worse (the double-occurences to depict the reflexiveness.) 1.2 Applications. We shall not be concerned with the properties of simple statements but merely with large programs of 1000-100000 lines of code (comments excluded). The motivation for this is that already known trouble-shooting techniques can easily, and mostly with success, be applied to simple statements and small programs. Furthermore it is commonly known that deterministic approaches cannot generally be applied to large systems or programs, as it is often seen that large, complicated systems not always do what one would expect them to do, that they often do what one actually would NOT expect them to do, and finally that they sometimes do nothing at all. This is also indicated by the fact that IF large programs behaved in a deterministic and predictable way and one could actually reason about them, the need of people maintaining and repairing such programs and systems would not be so explicit. Some have as a matter of fact stated, that if such people were not so much needed, they would probably turn to rather futile occupation as writing articles like this. Anyway, the bulk of the facts listed above combined with the results of section 1.1 states that: 1. If the behaviour of the program is not correct, i.e. it doesn't work, it is not necessarily due to any initial lack of well- definedness of neither the variables nor the program. Thus it is cumbersome to solve the problem with known analytical techniques. 2. If the program doesn't work, i.e. it is lousy?, an arbitrarily change S' in the program that will cause a nontrivial change P' in the properties of the behaviour of the program will fulfil P' < unimportant, that is, it will be unimportant or great!. Using that unimportant is a trivial change in the properties of the behaviour of the program and P' is a nontrivial change, we may conclude that the change is great!. This motivates the introduction of a new trouble-shooting technique called blind-shooting. The idea is to insert or delete, at random, statements of the program that is lousy?, until it will be correct, which will be great!. We shall formalize this with the following algorithm: Procedure BlindShooting(VAR program P): while <

> do <>; 1.3 Conclusion. The theory of Cowboy Programming provides an effective tool for correction of unpredictable errors that may and do arise in situations, where - someone else has written the source but left out the comments (or out of stupidity and/or malice only made misleading comments), and one has to make the program work in a rush. - one simply has to make the program work in a rush. - the automata, finite or infinite, on which the program should work is acting stupidly. A further perspective is, as Cowboy Programming gets more broadly used and recognized, to reduce the worldwide use of storage capacity by ommiting all comments in all programs, as they loose their importance anyway. Also, a lot of resources could be saved on hardware investments in more stable and reliable systems, as there are indications that problems concerning stability and reliability often are solved quicker and more effectively with Cowboy Programming. A known, Hungarian programmer recently said: "Khawboi Prokrammink brought ze funn back ento my life, yesz!" 1.3.1 Areas of future research. A major task for cowboy programmers and indeed cowboy analysists would be further to stress the relationship between blind-shooting theory and the problems that sometimes do arise from the so-called 'goto recursions' in Spaghetti Programming. This area has only been remotely investigated, and none but a few papers, that are characterized as 'Spaghetti-Western Theory', deal seriously with it. 1.4 Bibliography. None, what so ever.