BASIC
From Maze
(Difference between revisions)
(Elaborating and explaining two-sided platforms) | (→Programs in Human Memory) | ||
| Line 139: | Line 139: | ||
The idea that a page of code is easier to memorize than a random page of characters is supported by experimental studies. In an effort to better understand how people comprehend computer programs -- which has ramifications for programmer efficiency -- studies of program memorization were undertaken beginning in the mid-1970s. In 1976 Ben Shneiderman reported a statistically significant difference between subjects of different ability levels attempting to memorize a Fortran program and a series of valid Fortran statements in scrambled order, "leading us to the conclusion that the structure of a program facilitates comprehension and memorization." (p. 127) Part of the motivation for this study was the cognitive psychology literature on remembering sentences. | The idea that a page of code is easier to memorize than a random page of characters is supported by experimental studies. In an effort to better understand how people comprehend computer programs -- which has ramifications for programmer efficiency -- studies of program memorization were undertaken beginning in the mid-1970s. In 1976 Ben Shneiderman reported a statistically significant difference between subjects of different ability levels attempting to memorize a Fortran program and a series of valid Fortran statements in scrambled order, "leading us to the conclusion that the structure of a program facilitates comprehension and memorization." (p. 127) Part of the motivation for this study was the cognitive psychology literature on remembering sentences. | ||
| − | Ruven Brooks published a more elaborate theory of program comprehension in 1983. This is one in which a programmer reconstructs knowledge about the real-world domains that the program models, developing an initially underspecified hypothesis and refining and elaborating it "based on information extracted from the program text and other documentation." (p. 543) Brooks posited the useful idea that certain lines were "beacons," specially indicating program structures and operations. (p. 548) But his theory is otherwise difficult to apply to 10 PRINT .... Brooks lists seven internal and five external "indicators for the meaning of a program," such as "Indentation or pretty-printing" and "Flowcharts." (p. 551) None are present for the program that is the focus of this book. More fundamentally, Brooks's model is for programs that simulate business processes, not computer programs in general. He introduced a shipping domain in his paper, but then noted that "If the task is to implement a general algorithm for a general purpose routine, say a matrix inversion subroutine, there will be no domain corresponding to the original domain of cargoes and routes." (p. 545) In fact, the problem is not just with abstract processes and mathematical routines. Brooks's model cannot directly apply to any creative production that is done by programming the computer, unless it happens to also have a business-style real-world domain. What is the "cargoes and routes"-style domain of games, recreational programming, art, music, obfuscated code, or demos and intros from the demoscene? | + | Ruven Brooks published a more elaborate theory of program comprehension in 1983. This is one in which a programmer reconstructs knowledge about the real-world domains that the program models, developing an initially underspecified hypothesis and refining and elaborating it "based on information extracted from the program text and other documentation." (p. 543) Brooks posited the useful idea that certain lines were "beacons," specially indicating program structures and operations. (p. 548) But his theory is otherwise difficult to apply to 10 PRINT. Brooks lists seven internal and five external "indicators for the meaning of a program," such as "Indentation or pretty-printing" and "Flowcharts." (p. 551) None are present for the one-line program we are discussing here. More fundamentally, Brooks's model is for programs that simulate business processes, not computer programs in general. He introduced a shipping domain in his paper, but then noted that "If the task is to implement a general algorithm for a general purpose routine, say a matrix inversion subroutine, there will be no domain corresponding to the original domain of cargoes and routes." (p. 545) In fact, the problem is not just with abstract processes and mathematical routines. Brooks's model cannot directly apply to any creative production that is done by programming the computer, unless it happens to also have a business-style real-world domain. What is the "cargoes and routes"-style domain of games, recreational programming, art, music, obfuscated code, or productions such as demos and intros in the demoscene? |
Brooks's concept of beacons was used in another memorization study by Susan Widenbeck, published in 1986, in which a comprehension model with top-down and bottom-up aspects was introduced. Widenbeck found that beacon lines were recalled more often by experienced programmers. She also noted, "Memorizing a program is a very unusual programming task, and it is possible that it changed the subjects' normal program comprehension strategies and procedures." (p. 705) She found that program memorization was not like the memorization of text: "If subjects were taking a strictly linear, or text-reading, approach to understanding the program, we would expect the lines near the beginning of the program to be better remembered ... this was not the case." (p. 707) At the same time, she made analogies to the reading of texts in describing how her subjects read programs: "Using beacons to understand a program seems to be something like skimming an English text. They help to figure out the general, high-level function, but they do not contribute to a detailed understanding of the code ..." (p. 708) | Brooks's concept of beacons was used in another memorization study by Susan Widenbeck, published in 1986, in which a comprehension model with top-down and bottom-up aspects was introduced. Widenbeck found that beacon lines were recalled more often by experienced programmers. She also noted, "Memorizing a program is a very unusual programming task, and it is possible that it changed the subjects' normal program comprehension strategies and procedures." (p. 705) She found that program memorization was not like the memorization of text: "If subjects were taking a strictly linear, or text-reading, approach to understanding the program, we would expect the lines near the beginning of the program to be better remembered ... this was not the case." (p. 707) At the same time, she made analogies to the reading of texts in describing how her subjects read programs: "Using beacons to understand a program seems to be something like skimming an English text. They help to figure out the general, high-level function, but they do not contribute to a detailed understanding of the code ..." (p. 708) | ||
