BASIC
From Maze
(Difference between revisions)
(→Works Cited) | (→Programs in Human Memory) | ||
| Line 145: | Line 145: | ||
[More to come on Manuals, which I have still to consult for the first time] | [More to come on Manuals, which I have still to consult for the first time] | ||
| − | == Programs in Human Memory == | + | == BASIC Code in Human Memory == |
In today's computing context, it is hard enough to remember programs being transmitted on physical media such as floppy disks and cassette tapes. The notion that programs would routinely be published in print and typed by users is even more alien, but we do have material evidence that programs were transmitted in this way, and people are still invited to key in code snippets of different sorts from books on programming. | In today's computing context, it is hard enough to remember programs being transmitted on physical media such as floppy disks and cassette tapes. The notion that programs would routinely be published in print and typed by users is even more alien, but we do have material evidence that programs were transmitted in this way, and people are still invited to key in code snippets of different sorts from books on programming. | ||
| − | There is an even stranger way that programs, particularly short ones such as BASIC one-liners, got from computer to computer and from person to person: By being memorized. While it may not have been a ''Fahrenheit 451'' situation in which the world's great computer programs were preserved by a dedicated few, it was common for people who knew a bit of programming to keep a one-liner, or even a handful of short programs, in mind so that they could be typed into a friend's computer. | + | There is an even stranger way that programs, particularly short ones such as BASIC one-liners, got from computer to computer and from person to person: By being memorized. The claim here is not that the early 1980s presented a ''Fahrenheit 451'' situation in which the world's great computer programs were preserved by a dedicated few, but that it was common for people who knew a bit of programming to keep a one-liner, or even a handful of short programs, in mind so that they could be typed into a friend's computer. Very short programs that did visually interesting things were particularly worth memorizing. And since programmers typically had to memorize certain BASIC statements, such as <code>? CHR$(147)</code> (which clears the screen), it was not much of a leap to memorize two statements, such as <code>10 PRINT CHR$(205.5+RND(1)); : GOTO 10</code>. |
The dream of having total recall of a massive computer program manifests itself in science fiction. In Cory Doctorow's story "0wnz0red," the main character, Murray, is initially a fat slob who, after the death of his only friend Liam, has spiraled downwards personally and in terms of code quality. After Liam returns, having actually hacked his body and mind into near-perfection, Murray is provided with similarly superhuman abilities, including the ability to exactly remember large amounts of English text: "... generating a 4,096 bit key that he could remember was going to be damned hard, but then he closed his eyes and recalled, with perfect clarity, the first five pages of documentation he'd written for the API. His fingers rattled on the keys at speed, zero typos." The keyboard isn't essential to this process: Later, while hooded and being interrogated, Murray recites the entire key. | The dream of having total recall of a massive computer program manifests itself in science fiction. In Cory Doctorow's story "0wnz0red," the main character, Murray, is initially a fat slob who, after the death of his only friend Liam, has spiraled downwards personally and in terms of code quality. After Liam returns, having actually hacked his body and mind into near-perfection, Murray is provided with similarly superhuman abilities, including the ability to exactly remember large amounts of English text: "... generating a 4,096 bit key that he could remember was going to be damned hard, but then he closed his eyes and recalled, with perfect clarity, the first five pages of documentation he'd written for the API. His fingers rattled on the keys at speed, zero typos." The keyboard isn't essential to this process: Later, while hooded and being interrogated, Murray recites the entire key. | ||
| Line 159: | Line 159: | ||
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 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? | + | Ruven Brooks published a more elaborate theory of program comprehension in 1983; 10 PRINT shows some interesting ways in which this theory breaks down. In Brooks's theory, 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) | ||
| Line 165: | Line 165: | ||
Shneiderman's early acknowledgement that programs can be memorized is significant; his result, furthermore, shows that the memorization of programs relates to the memorization of language in some important ways. But there are differences between this study's perspective and the consideration of how BASIC one-liners are memorized. Shneiderman focuses on comprehension and uses memorization as a measure of comprehension; although it seems evident from all of these studies that two are deeply connected, memorization is nevertheless being considered along the way to understanding something else. Shneiderman's study is about the short-term memorization of programs of about 20 lines, assigned as a task. Because short-term memory is the concern, Shneiderman cites the famous paper on the topic, Miller's 1956 "The magical number seven, plus or minus two," and discusses how his results may be consistent with the ones in that paper. | Shneiderman's early acknowledgement that programs can be memorized is significant; his result, furthermore, shows that the memorization of programs relates to the memorization of language in some important ways. But there are differences between this study's perspective and the consideration of how BASIC one-liners are memorized. Shneiderman focuses on comprehension and uses memorization as a measure of comprehension; although it seems evident from all of these studies that two are deeply connected, memorization is nevertheless being considered along the way to understanding something else. Shneiderman's study is about the short-term memorization of programs of about 20 lines, assigned as a task. Because short-term memory is the concern, Shneiderman cites the famous paper on the topic, Miller's 1956 "The magical number seven, plus or minus two," and discusses how his results may be consistent with the ones in that paper. | ||
| − | The memorization of BASIC one-liners is more long-term, is done for fun, and of course involves shorter programs. This type of memorization will have certain things in common with the type done in these memorization studies, but it may also relate to the way people memorize jokes, proverbs, and other other texts. These studies do at least show how people can remember key statements (beacons) and the high-level workings of a program without memorizing it character by character. Also, the appearance of program variants that work identically but are written differently is consistent with studies on and theories of program memorization. And, essentially, the studies demonstrate that program memorization is possible and that many people may have carried 10 PRINT into a Commodore 64's memory using their own. | + | The point here is not to advance an alternative theory of program memorization, but to show that 10 PRINT represents a category of programs that were historically memorized but which existing theories of program memorization, created for longer program and for programs that model business processes, do not cover. The memorization of BASIC one-liners was rather long-term, was done for fun, and of course involved very short programs. This type of memorization will have certain things in common with the type done in these memorization studies, but it may also relate to the way people memorize jokes, proverbs, and other folk texts. These studies do at least show how people can remember key statements (beacons) and the high-level workings of a program without memorizing it character by character. Also, the appearance of program variants that work identically but are written differently is consistent with studies on and theories of program memorization. And, essentially, the studies demonstrate that program memorization is possible and that many people may have carried 10 PRINT into a Commodore 64's memory using their own. |
| + | |||
| + | == Sidebar: Remembering 10 PRINT == | ||
| + | |||
| + | When I first brought a similarly-functioning program up for discussion, I presented this version: <code>10 PRINT CHR$(109+RND(1)*2); : GOTO 10</code>. That's the program I discussed very briefly in my article "Obfuscated Code" in ''Software Studies: A Lexicon,'' and that's the same text I presented to Mark Marino's online Critical Code Studies Workshop, where it sparked the discussion that led to this book. It does the same thing as our title program, for two reasons: First, 205 and 206 are mapped to the same characters as 109 and 110; second, adding a random number between 0 and 2 does the same thing as adding .5 and adding a random number between 0 and 1. The version we use in the title is based on (but not identical to) two early print sources for the program, the three-line program in the ''Commodore 64 Users Guide'' and the one-line version in ''RUN Magazine.'' There are no print sources from the 1980s that we have found that use "RND(1)*2" or that use 109/110 rather than 205/206. | ||
| + | |||
| + | Why did I initially bring up this "corrupt" version of the program? Simply because I reconstructed 10 PRINT from memory and looked at a chart of "PETSCII" characters values when I was doing so. Since 109/110 are lower down and closer to the characters A-Z, I ran into them first and used those values. | ||
| + | |||
| + | Our discussion of this program is based on the print versions of it that I found early in the process of working on this book -- but the version of the program that started our discussion came from my memory. | ||
| + | |||
| + | -Nick Montfort | ||
== Works Cited == | == Works Cited == | ||
