Regularity
From Maze
(Difference between revisions)
(Unprotected "Regularity": Done) | (Edits to Dijkstra sidebar, beginning of Loops) | ||
| Line 149: | Line 149: | ||
= The Loop: Repetition in Process = | = The Loop: Repetition in Process = | ||
| − | To explain the loop, it's necessary to explain the alternative: Not having a loop, letting a program progress in the usual sequence. 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: | + | The execution of a computer program, even one that is riddled with bugs or does numerous complex and interesting things, is nothing if not regular. Part of what gives programs their power is that they can be even more regular by repeating a sequence of instructions. This repetition can be accomplished in two main ways: in a loop that continues for a certain number of iterations or in an unbounded loop. These two loops correspond to two types of branching, the conditional and unconditional branch. Understanding the unbounded loop of 10 PRINT (and what it is not) provides an introduction to the essential aspects of the flow of control in computer programs. |
| + | |||
| + | To explain the loop, it's necessary to first explain the alternative: Not having a loop and letting a program progress in the usual sequence. 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: | ||
<nowiki>PRINT "FIRST": PRINT "SECOND"</nowiki> | <nowiki>PRINT "FIRST": PRINT "SECOND"</nowiki> | ||
| Line 208: | Line 210: | ||
This would certainly be a clearer way to write the program, and it would be widely recognized today as clearer because Dijkstra's view of programming has prevailed. When the creators of BASIC introduced a new version, True BASIC, in 1988, they included the "DO" loop; its syntax was a bit different from the above, but the essential construct was the same. | This would certainly be a clearer way to write the program, and it would be widely recognized today as clearer because Dijkstra's view of programming has prevailed. When the creators of BASIC introduced a new version, True BASIC, in 1988, they included the "DO" loop; its syntax was a bit different from the above, but the essential construct was the same. | ||
| − | Although this important construct is missing from early versions of BASIC, it's not obvious that the tiny program 10 PRINT would have particularly offended Dijkstra. In his letter, he objects to the "unbridled use of the '''go to''' statement" and does not state that ''every'' use of it is unambiguously bad. He describes the GOTO-related problems that arise when programmers are not able to track and understand the values of variables. But 10 PRINT has no variables, so this particular problem with GOTO is not an issue. | + | Although this important construct is missing from early versions of BASIC, it's not obvious that the tiny program 10 PRINT would have particularly offended Dijkstra. In his letter, he objects to the "unbridled use of the '''go to''' statement" and does not state that ''every'' use of it is unambiguously bad. He describes the GOTO-related problems that arise when programmers are not able to track and understand the values of variables. But 10 PRINT has no variables, so this particular problem with GOTO is not an issue in this particular case. |
The equivalent of a GOTO statement is a staple of machine language programming; it is the unconditional branch, JMP. Dijkstra essentially exempted machine language from his critique of GOTO. He recognized that computer programs written in a high level language are more complicated and nuanced ways of expressing thought, not tied directly to machine function. By creating a new sort of language that does not directly mimic the operation of the processor, it is possible for programmers to think more flexibly and powerfully. Although Dijkstra objected to the way BASIC was designed, he, like the original designers of BASIC, worked strenuously to describe how high-level languages, useful for thinking about computation, could work in machine-independent ways. | The equivalent of a GOTO statement is a staple of machine language programming; it is the unconditional branch, JMP. Dijkstra essentially exempted machine language from his critique of GOTO. He recognized that computer programs written in a high level language are more complicated and nuanced ways of expressing thought, not tied directly to machine function. By creating a new sort of language that does not directly mimic the operation of the processor, it is possible for programmers to think more flexibly and powerfully. Although Dijkstra objected to the way BASIC was designed, he, like the original designers of BASIC, worked strenuously to describe how high-level languages, useful for thinking about computation, could work in machine-independent ways. | ||
| Line 222: | Line 224: | ||
Some of the context for these statements is the formation and fortification of a discipline, computer science, and the development and use of languages that might support first formal verification (the provability of programs) and later the weaker but still potentially very useful technique of program derivation (Tribble 2005). BASIC, created for quick interactive use and very amenable to creative production, was simply not a suitable language for Dijkstra's desiderata. | Some of the context for these statements is the formation and fortification of a discipline, computer science, and the development and use of languages that might support first formal verification (the provability of programs) and later the weaker but still potentially very useful technique of program derivation (Tribble 2005). BASIC, created for quick interactive use and very amenable to creative production, was simply not a suitable language for Dijkstra's desiderata. | ||
| − | Another bit of context for these statements comes from Alan Kay, who remarked in his keynote speech to the 1997 Object-Oriented Programming, Systems, Languages & Applications conference: "I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." | + | Much of Dijkstra's influential thinking (about stepwise programming, for instance) applies most clearly to programs of some complexity. It would be difficult to develop a program as simple as 10 PRINT using stepwise programming, since it only takes about one step to write it. As mentioned, 10 PRINT is in a sense exempt from Dijkstra's critique of GOTO because of its lack of variables. But in another sense, it is one of many extremely simplified programs that could lead programmers to learn programming methods that don't scale. The risk of learning programming via one-liners is that one learns tricks and particular methods instead of gaining an understanding of programming methodologies. |
== Bounded and Unbounded Loops == | == Bounded and Unbounded Loops == | ||
| Line 287: | Line 289: | ||
Computing is full of iterations and simple loops. The highest level of an application program is typically the "main loop" that checks for user input and for other events. Turn-based games, such as a chess program that plays against a human player, will typically have a conditional loop for each turn, conditioned upon whether or not the game is over. And frames of a graphics window or the screen overall, whether they are being drawn in OpenGL, Processing, or by some other means, are drawn within a loop that repeats more or less rapidly depending upon the framework. | Computing is full of iterations and simple loops. The highest level of an application program is typically the "main loop" that checks for user input and for other events. Turn-based games, such as a chess program that plays against a human player, will typically have a conditional loop for each turn, conditioned upon whether or not the game is over. And frames of a graphics window or the screen overall, whether they are being drawn in OpenGL, Processing, or by some other means, are drawn within a loop that repeats more or less rapidly depending upon the framework. | ||
| − | = Conclusion = | + | = Generative Repetition = |
10 PRINT offers in its single line a sense of the generative potential of the rhythmic repetition of a very simple process, "Generative" in this context refers to work that is derived from a fixed system. The most cited definition for generative art was written by Philip Galanter: | 10 PRINT offers in its single line a sense of the generative potential of the rhythmic repetition of a very simple process, "Generative" in this context refers to work that is derived from a fixed system. The most cited definition for generative art was written by Philip Galanter: | ||
| Line 307: | Line 309: | ||
Gombrich, E.H. The Sense of Order: A Study in the Psychology of Decorative Art. 2nd ed. Phaidon Press, 1994. Print. | Gombrich, E.H. The Sense of Order: A Study in the Psychology of Decorative Art. 2nd ed. Phaidon Press, 1994. Print. | ||
| + | Harrison, E. ''The Young Ladies' Journal Complete Guide to the Work-Table.'' 1885. | ||
| + | |||
Montfort, Nick. "Continuous Paper: The Early Materiality and Workings of Electronic Literature." Modern Language Association (MLA) Convention, Philadelphia, 28 December 2004. | Montfort, Nick. "Continuous Paper: The Early Materiality and Workings of Electronic Literature." Modern Language Association (MLA) Convention, Philadelphia, 28 December 2004. | ||
| Line 319: | Line 323: | ||
Rickey, George. Constructivism: Origins and Evolution. New York: George Braziller, 1967. | Rickey, George. Constructivism: Origins and Evolution. New York: George Braziller, 1967. | ||
| − | The YoungLadies' Journal Complete Guide to the Work-Table. E. Harrison, 1885. | ||
| − | |||
Zelevanksy, Lynn. Beyond Geometry: Experiments in Form, 1940s-70s. Cambridge: MIT Press, 2004. | Zelevanksy, Lynn. Beyond Geometry: Experiments in Form, 1940s-70s. Cambridge: MIT Press, 2004. | ||
