BASIC
From Maze
(Difference between revisions)
(→Works Cited) | (→BASIC Code in Human Memory) | ||
| Line 192: | Line 192: | ||
== BASIC Code in Human Memory == | == BASIC Code in Human Memory == | ||
| − | Many have difficulty now remembering 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. Programs were indeed transmitted in this way, though; a hint of this is still seen when people are invited to key in code snippets from books on programming. | + | Not so long ago, software was primarily transmitted on physical media, such as cassette tapes, floppy disks, and CD-ROMs. The notion that programs would routinely be published in print and typed in by users seems alien now. But there is an even stranger way that programs, particularly short ones such as BASIC one-liners could make their way from computer to computer and from person to person: as memorized pieces of code, like a software virus whose host is a human rather than a machine. |
| − | There is an even stranger way that programs, particularly short ones such as BASIC one-liners sometimes made their way from computer to computer and from person to person: by being memorized. This is not to say 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 remember a one-liner, or a handful of short programs, so that they could be typed into a friend's computer. Very short programs that did visually interesting things were particularly worth memorizing; in the late 1970s and early 1980s, the mass of these were of course in BASIC. (See "Remarks: One-Liners" for several examples.) 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 a program that contained two statements in that language, such as <code>10 PRINT CHR$(205.5+RND(1)); : GOTO 10</code>. | + | The dream of total recall of a computer program appears in science fiction. In Cory Doctorow's short story "0wnz0red," the programmer Murray spirals downwards in his code quality after the apparent death of his only friend. When his friend returns, having actually hacked his body and mind into near-perfection, Murray is provided with similarly superhuman capabilities. Among these is the ability to precisely remember large amounts of text, including technical documentation of code, which "he closed his eyes and recalled, with perfect clarity." Murray's powers of recall even extend beyond human language. As the story ends, Murray "had the laptop open and began to rekey the entire codebase, the eidetic rush of perfect memory dispelled all his nervousness, leaving him cool and calm as the sun set over the Mission." |
| − | 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, who initially appears as a fat slob who, after the death of his only friend Liam, spirals 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. In the culminating moment of "0wnz0red," it is revealed that while Murray apparently can't easily memorize a random sequence of characters, his powers of recall extend beyond human language: "once he had the laptop open and began to rekey the entire codebase, the eidetic rush of perfect memory dispelled all his nervousness, leaving him cool and calm as the sun set over the Mission." Murray is human enough that he cannot recall an arbitrary 4KB, but enough of a savant that he can perfectly remember not only documentation but a mass of code. | + | Doctorow's story makes it clear that the ability to memorize a large program is a superpower; that is, it is not an ordinary human ability and for many programmers, it would be a truly awesome power. At the same time, the story's treatment of the human body and mind as machines that can be mastered by a programmer and owned (or even 0wnz0red) by an adversary, is consistent with the idea that memorizing code is enslaving one mind's to the machine, treating it as a storage peripheral. For many programmers, however, memorizing one-liners (not the entire codebase) is both possible and useful. And in the case of home computing in the early 1980s, it could be advantageous for someone to memorize a one-liner, or a handful of short programs. A memorized one-liner could be typed into a friend's computer, initiating a kind of two-way cultural economy; in exchange for sharing a particularly interesting or visually affecting program, one earned prestige, or street cred, a currency a teenager in 1982 would surely appreciate. In the late 1970s and early 1980s, the mass of these short programs worth memorizing were of course in BASIC. (See "Remarks: One-Liners" for several examples.) And because programmers typically had to memorize certain BASIC statements anyway, such as <code>? CHR$(147)</code> (which clears the screen), it was not much of a leap to memorize a program that contained two statements in that language, such as <code>10 PRINT CHR$(205.5+RND(1)); : GOTO 10</code>. |
| − | Doctorow's story makes it clear that the ability to memorize a large program is a superpower; that is, it is not an ordinary human ability and it is furthermore an ability that is awesome, desirable, and elite. At the same time, the story's treatment of the human body and mind as comptuerlike, as capable of being mastered by a programmer and owned (or even 0wnz0red) by an adversary, is consistent with the idea that memorizing code is slaving one mind's to the machine, treating it as a storage peripheral. | + | Moving beyond the economy of prestige, there are strictly utilitarian reasons to memorize a short program. For example, Perl is used for a wide variety of text processing tasks; many who program in it find it useful to write, recall, or adapt one-line programs that work on the command line. For instance, to convert a file <code>dosfile.txt</code> with DOS-style line endings to Unix format, a common task for many programmers, the carriage returns (\r) must be removed. This can be accomplished with the command <code>perl -p -i -e 's/\r\n/\n/g' dosfile.txt</code> which includes a very short program (between quotes) to perform the needed substitution. With a few changes, this code can be adapted to replace one word with another, for instance, substituting "Commodore" for every occurrence of "Atari": <code>perl -p -i -e 's/Atari/Commodore/g' manuscript.txt</code>. |
| − | |||
| − | For many programmers, however, memorizing one-liners (not the entire codebase) is both possible and useful. Perl is used for a wide variety of text processing tasks; many who program in it find it useful to write, recall, or adapt one-line programs that work on the command line. For instance, to convert a file <code>dosfile.txt</code> with DOS-style line endings to Unix format, a common task for many programmers, the carriage returns (\r) must be removed. This can be accomplished with the command <code>perl -p -i -e 's/\r\n/\n/g' dosfile.txt</code> which includes a very short program (between quotes) to perform the needed substitution. With a few changes, this code can be adapted to replace one word with another, for instance, substituting "Commodore" for every occurrence of "Atari": <code>perl -p -i -e 's/Atari/Commodore/g' manuscript.txt</code>. | ||
Programmers who use such Perl one-liners do not seem to remember them the way one memorizes lines from a play or a song. They would generally understand how the substitution operator (<code>s///</code>) functions and how command-line flags to Perl work. In other words it is knowing Perl, not just the memorization of a string of symbols, that is important to most uses of Perl one-liners. But the phrase "Perl pie" does helps some to quickly recall which command-line flags are needed in this case, and one-liners are at times as much recalled as figured out and programmed. Many common one-liners are not programmed "from scratch" each time they are used. | Programmers who use such Perl one-liners do not seem to remember them the way one memorizes lines from a play or a song. They would generally understand how the substitution operator (<code>s///</code>) functions and how command-line flags to Perl work. In other words it is knowing Perl, not just the memorization of a string of symbols, that is important to most uses of Perl one-liners. But the phrase "Perl pie" does helps some to quickly recall which command-line flags are needed in this case, and one-liners are at times as much recalled as figured out and programmed. Many common one-liners are not programmed "from scratch" each time they are used. | ||
| − | This type of non-rote memorization is the sort that BASIC programmers also employed in bringing 10 PRINT from one computer to another to show off its output. Remembering code, like having it printed with the occasional typo, was a "lossy" way to transmit programs. This didn't have purely negative effects, though. Instead of the prefect but opaque way of transferring files via disk or download, the recall and reading of programs left a space for the programmer to work and play. If the recalled version of the program didn't work correctly, the programmer could think about how to change it. If it did work well, the programmer might think to change it further to see what could be done. The wiring of these printed and memorized programs was sometimes messed up, but they were also not in a closed black box. | + | This type of non-rote memorization is the sort that BASIC programmers also employed in bringing 10 PRINT from one computer to another as they showed off its output. Remembering code, like having it printed with the occasional typo, was a "lossy" way to transmit programs. This didn't have purely negative effects, though. Instead of the perfect but opaque way of transferring files via disk or download, the recall and reading of programs left a space for the programmer to work and play. If the recalled version of the program didn't work correctly, the programmer could think about how to change it. If it did work well, the programmer might think to change it further to see what could be done. The wiring of these printed and memorized programs was sometimes messed up, but they were also not in a closed black box. |
== Studies of Program Memorization (Sidebar) == | == Studies of Program Memorization (Sidebar) == | ||
