Regularity
From Maze
The Grid: Regularity in Space
Repeating: Regularity in Time and Process
The Flow of Control
In any imperative programming language, commands are processed in a particular order that relates to the left-to-right, then top-to-bottom path that the Western reader's eyes stereotypically take along a page. If one types in two PRINT commands directly to the Commodore 64's BASIC interpreter, with a colon between them, like so:
PRINT "FIRST": PRINT "SECOND"
The result is
FIRST SECOND
The command on the left is executed first; then, probably not very surprisingly, the command on the right is carried out. In executing the following program, the topmost, leftmost command is run first, then the one to the right, and then the one on the next line, so that three lines that read FIRST, SECOND, and THIRD are printed:
10 PRINT "FIRST": PRINT "SECOND" 20 PRINT "THIRD"
The order in which these two lines are actually typed in by the programmer is completely irrelevant to how the program runs. The lines of a BASIC program are executed based on their line numbers, not based on when lines were entered.
There are some important ways to complicate this straightforward program flow. All of these ways involve branching, which causes program flow to continue at some other command rather than what would is, according to left-to-right, top-to-bottom program structure, the next one.
Conditional and Unconditional Branching
At a low level, an executing program can either continue to process the next instruction or can move out of sequence to process a different instruction. Just as a reader of a text will typically move to the next word or line, the usual case in the execution of a program is to move to the next instruction. This involves incrementing the program counter so that it points to the place where code is located in memory. If the current instruction is one that can change the flow of control, however, the program may jump or branch to a new memory location and a new piece of code.
There are two ways to branch. An unconditional branch always directs the program to jump to a new location, like the instruction "Go directly to Jail -- do not pass Go" in Monopoly. The assembly mnemonic for an unconditional branch is JMP; the corresponding BASIC keyword is GOTO.
When an unconditional branch is used to point back to an earlier instruction, it can accomplish repetition in process. In 10 PRINT, the GOTO command is used to cause the program to loop, so that the PRINT command is repeated again and again.
The other type of branch is a conditional branch, a type of instruction that is critical to general-purpose computing. There are many different types of conditional branches in assembly, since there are many different types of conditions. BEQ is "branch if equal," for instance; when used after a comparison (CMP), the branch will be taken only if the compared values are equal. BMI, "branch if minus," checks to see if the last computation resulted in a negative value. In BASIC, using the IF ... THEN statement is the most straightforward way to accomplish a conditional branch, as this program demonstrates:
10 INPUT A$ 20 IF A$ = "1" THEN PRINT "ONE" : END 30 PRINT "SOMETHING ELSE"
If, after running this program, the user types just the digit "1" and then presses RETURN, all of the statements on line 20 will be executed. "ONE" will be printed and then the program will terminate as END instructs. If the user types anything else before pressing RETURN, the flow of control moves to line 30 and PRINT "ONE" and END are skipped. "SOMETHING ELSE" is printed instead.
Although there is no IF ... THEN statement in 10 PRINT, and the program does not by any interpretation contain a conditional branch, this short program does accomplish a very small-scale sort of variation. By computing 205.5+RND(1) and passing that value to the function CHR$, the program prints either PETSCII character 205 or PETSCII character 206. This variation between two characters is a one-bit variation, a selection from the smallest possible set of options. Yet, in combination with the regularity of a repeating processes and the regularity of the Commodore 64's screen grid, these selections take shape as something evocative and visually interesting.
Iteration – code and structures
"Go To Statement Considered Harmful"
In the case of 10 Print the GOTO statement avoids most of Dijkstra's complaints. Putting a GOTO statement at the end of a one-line program that simply references itself does not leave much room for unexpected entrances and exits. However, expanding the program to take more than one line demonstrates the potential problems that GOTO introduces:
5 CHARCODE%=205.5+RND(1) 10 PRINT CHR$(CHARCODE%); 20 GOTO 5
This code is functionally identical to the one-line version of 10 Print, but is a bit more representative of how developers create more complex programs. Line 5 creates a variable called CHARCODE% that stores a character code determined by the same formula used in the original 10 Print, but the character code is not used until line 10 when it is printed to the screen. Line 20 has the GOTO statement that makes the program iterate, but it now points to the new beginning of the program at line 5.
Already there is one potential problem: what if the programmer had forgotten to change GOTO's target from line 10 to line 5? The program would still function, but since the loop only returns to line 10 CHARCODE% never changes and the program only prints the same character over and over again with no randomization. Nowhere in this code does it say that the computer must select a random character code every time it prints a character, it is only implied by the fact that line 10 comes after line 5. GOTO allows the programmer to reference any line of code, however; it is just as valid to say GOTO 10 as it is GOTO 5, regardless of the intention that line 10 always executes right after line 5. GOTO's ability to target arbitrary line numbers means that sections of code that are intended to be monolithic can be entered at any point instead of just the beginning of the block.
GOTO's potential problems only get worse when it is combined with other flow control statements. Consider this variant of 10 Print:
1 FOR I = 0 TO 999 5 CHARCODE%=205.5+RND(1) 10 POKE 1024+I,CHARCODE% 15 NEXT I 20 GOTO 1
This version uses a FOR loop to fill the entire screen with the two 10 Print characters, beginning at the top-left corner. Immediately after finishing the FOR loop the program hits line 20 and GOTO sends execution back to line 1, restarting the loop from the beginning. If the forgetful programmer again fails to update line 20 though, leaving it as:
20 GOTO 5
The program will now not only fail to work as intended, it will fail to work at all and throw an error:
? NEXT WITHOUT FOR ERROR IN 15
Unlike the previous version where lines 5 and 10 were only implied to be a block, lines 1-15 are now explicitly a block of code defined as a FOR loop. NEXT relies on FOR, but since the block was re-entered on line 5 FOR never executes and NEXT is no longer valid. Using GOTO has short-circuited the other flow control structures that are critical to the language.
(tk may be clearer with diagram?)
Structured programming
Dijkstra's comments about GOTO were part of a movement toward programming languages that are designed for structured programming. Dijkstra himself would later take the idea further in his Notes on Structured Programming. Instead of viewing a program as line after line of text, structured programming practices involve seeing a program as an abstract set of tasks to be completed. Each of these tasks can be completed independent of one another; one section of the program can be written without worrying about how it is going to reference other sections because they share a common method of moving data between them. At a high level, programmers do not need to worry about how each function will work, they just know that it will and this knowledge allows them to plan their code strategically. Dijkstra compared this model to a string of pearls:
One of the metaphors in which I find myself thinking about the program structure envisaged regards the programs as a necklace, strung from individual pearls. We have described the program in terms of levels and each level contained "refinements" of entities that were assumed available in higher levels. […] I use the term "pearl" for [individual functions].
OOP
Recursion
Design and feedback
Iterative design
Testing as development
Agility and reuse
= Iteration – software and business=
Mechanical reproduction
Version 1.0
Break
Iteration as a Generalized Process
Bread and Beer
Fractals and Chaos
Life
Works Cited
Anon. 1964. BASIC. Dartmouth College: Computation Center.
