BASIC

From Maze

Revision as of 12:13, 2 April 2011 by PatsyBaudoin (Talk | contribs) (→Circulating Programs in Print)
Jump to: navigation, search

Contents

[hide]
  • 1 A Brief History of Programming
  • 2 Dartmouth BASIC and Time-Sharing Minicomputers
  • 3 Altair BASIC and Microcomputers
  • 4 Circulating Programs in Print
  • 5 Programs in Human Memory
  • 6 Works Cited
  • Unquestionably, an important aspect of 10 PRINT is that it is written in a particular programming language, BASIC, which itself has an interesting cultural and technical history. An acronym for "Beginner's All-purpose Symbolic Instruction Code," BASIC was developed by John Kemeny and Thomas Kurtz, two professors at Dartmouth College; it became operational in 1964 and was freely shared by its creators, leading to its use in high schools among other contexts. By that time, general-purpose computers had been programmed for about two decades and high-level languages (of which BASIC is one example) had been in widespread use for a decade. While BASIC has distinguishing features, it also continues the history of high-level languages, particularly Fortran and Algol.

    BASIC's invention in an educational context signals one important aspects of its use. The language was developed for use in time-sharing environments - specifically, for use in the Dartmouth Time-Sharing System. This sort of setup was revolutionary in allowing many programmers to use a single system interactively at the same time. The configuration of such a system, with many terminals connected to a mainframe or minicomputer, was very different from that of the personally owned, inexpensive, single-user computers of the microcomputer era. It was also very different from the batch processing of jobs punched out on card, though. Time sharing allowed people to engage with and explore computation in significant new ways, and BASIC was an important part of this computing revolution.

    The story of BASIC becomes even more interesting as microcomputers come to market and into people's homes. In 1975, the MITS Altair 8800 computer became available, provided in a kit which the purchaser had to assemble. This computer was widely acclaimed as the first home computer. Perhaps the most significant piece of software for this system was Altair BASIC, an interpreter for the BASIC programming language that was the first product of a new startup company, known at the time as "Micro-Soft." The company didn't stop at this version. Thanks in large part to Microsoft, BASIC became the lingua franca of home computing. Microsoft's versions were standard on many popular microcomputers, provided in ROM so that the computer could be turned on and immediately programmed. BASIC reigned in the late 1970s and through the early 1980s, when 10 PRINT circulated in print and was being keyed in by numerous users. It was so obvious that this language was the language of choice that some books of BASIC programs do not even find it necessary to mention "BASIC" on their cover or in introducing the book.

    While the heyday of the language did not last, interesting new versions of BASIC, sometimes radically reformulated, continued to appear. The creators of the original language introduced True BASIC in 1983. In 1985, Microsoft's QuickBASIC offered several innovations and, for instance, made line numbers options. And Microsoft's even more radically different Visual Basic saw widespread use in creating business applications.

    BASIC (along with COBOL) seems to be one of the major whipping boys among programming languages. Inextricably associated with Microsoft and that bane of structured programmers, GOTO, it is said to encourage the writing of spaghetti code, to be unbearably slow, and to be suitable only for children and amateurs. Yet many programmers in the early 21st century remember BASIC fondly - as they should. The language was a popular success, worked well for small programs that tested the possibilities of computing, and fostered creativity and innovation by new categories of computer users.

    A Brief History of Programming

    Dartmouth BASIC and Time-Sharing Minicomputers

    [Notes: Include several paragraphs emphasizing that BASIC was designed with beginner's in mind. Here's some draft text]

    The "B" in BASIC was not simply a rhetorical move. The creators of BASIC sincerely wanted a language that novices could start using within minutes of study. This intent is clearly reflected in some of BASIC's original design principles. BASIC should, Kemeny and Kurtz decided, "give error messages that were clear and friendly" and provide default options that satisfy most users' needs (9). "If the expert needs something fancier," Kemeny and Kurtz declared, "let the expert do the extra work!" (11). Furthermore, BASIC was intended truly as a high level language, meaning programmers would need little knowledge of the actual processes underlying the code--the low level machine instructions. BASIC's designers were adamant about making everything except BASIC itself transparent to the programmer: "No understanding of the hardware should be necessary" and "It should shield the user from the operating system" were two initial goals of BASIC, in fact (9).

    Ironically, 10 PRINT highlights the failure of this transparency. The code makes little sense unless one knows the Commodore 64's idiosyncratic character set. There is no shielding the user from the operating system in 10 PRINT. Indeed, there is no escaping it.

    The original version of BASIC introduced another concept to programming that is readily apparent in 10 PRINT: the line number. Prior to BASIC, computing jobs were performed by batch processing. A program consisted of a stack of IBM keypunch cards, submitted to the computer. Multiple programs would be feed into the computer, which would then execute them one-by-one, printing out the results. When all of the programs had been run, another batch could be given to it. Any error in any keycard would result in an unexecutable program; debugging was a long and painful process. Line numbers solved the problem, or at least made it easier to pinpoint errors. An error in a program meant only the offending line had to be retyped, rather than an entire keycard repunched.

    The concept of line numbers was so unconventional at the time that the original BASIC instruction manual from 1964 went into some detail concerning their use: line numbers must be "no more than five digits," "contain no spaces or non-digit numbers," and finally "start at the very beginning of the line" (17-18)--all restrictions that modern users might take for granted but at the time were hardly self-evident. It's difficult to overstate the value of line numbers to BASIC. Line numbers were not simply after-thoughts to the language, they were constitutive of the language itself, part of its very ethos. For example, line numbers made it easy to delete existing lines; simply type the line number without any further instructions, and the line disappears. To correct a single existing line, rewrite the line with the same line number.

    The practice of numbering program statements by multiples of five or ten is not merely aesthetic; the insertion of new lines in a program requires that, as the 1964 manual puts it, "the original line numbers not be consecutive numbers" (22). Numbering a program 10, 20, 30, and so on ensured that between every existing program statement there was room for nine more.

    This convention makes several of the variations of 10 PRINT found "in the wild" stand out. For example, the three-line version in the C64 User Manual skips line 30, an intriguing absence that has no bearing on the program's process but which nonetheless stands out when the program is LISTed. The irregularity of the line numbering in this instance is particularly striking because the very same C64 manual advises that "it is good programming practice to number lines in increments of 10--in case you need to insert some statements later on" (33). Likewise, the one-line variant of 10 PRINT found in an issue of Run from 1984 begins with the line number 8, a seemingly arbitrary line number that obviously defies the increment of ten "good programming practice." Is this irregularity actually arbitrary though? Taken in context of the entire program--

    8 PRINT CHR$(205.5 + RND(8)); : GOTO 8
    

    --one wonders if the odd (that is, even) line number is meant to create further mystification about the program's purpose. It's easy to imagine a novice to BASIC confusing the function of the 8's that bookmark the program with the third 8 embedded in the RND function. Understood this way, the line number 8 becomes precisely want the creators of BASIC hadn't intended: an aesthetic device, creating a visual internal symmetry within the program.

    In 1985, the developers of BASIC argued that "until the appearance of modern screen editors, the line-numbering system we devised was the easiest editing system available" (12). It's worth nothing that the Commodore 64 sat at the cusp of line-numbering editing and visual screen editors. It was possible with the C64 to edit a line of BASIC without retyping the entire line. Using a combination of SHIFT, ARROW, and INST/DEL keys, it was easy enough with the Commodore to edit a few characters of a line. One can't help wonder whether this move toward visual line editing, though a boon to programming in general, was an anathema to the ethos of BASIC, a sign of proliferating complexity.

    Altair BASIC and Microcomputers

    Circulating Programs in Print

    At issue in this section of our chapter on the transmission of BASIC in print is what print vehicles users disseminated to communicate the BASIC language, its uses, and its programs. In looking at the specifics of how BASIC was disseminated and traveled between and among different user communities, we will uncover interesting signs about the practices BASIC users developed, the habits they fell into, the culture that developed among them, and finally the trends they set and that now inflect the history of computing in more and less significant ways.

    Kemeny & Kurtz designed BASIC for time-sharing systems in 1964 , when time-sharing computers were themselves still quite new. Time-sharing computers transformed computing in several important ways. On one hand time-sharing rendered computer time more efficient since idle time were dramatically reduced. One the other hand and of particular importance to us is the fact that time-sharing meant many simultaneous users could share computing power. The time-sharing model offered those who could not own a computer access to computing time that they could more easily afford. That BASIC should be designed for time-sharing computing is worth noting. It reflects the opportunity time-sharing computers opened for designing interactive development of new applications. The impulse of BASIC – Beginner's All-purpose Symbolic Instruction Code – was, after all, in part to provide easier access to the wonders of programming. The upshot, an easy-to-learn language on a system that made access more broadly available, marks a turning point in the history of computing. That this simplified and accessible model should claim space on college campuses first and then in schools thereafter is therefore hardly surprising.


    [find out more about BASIC’s transmission in print before the mid-1970s]


    From the mid-1970s through the early 1980s, the transmission of BASIC in print took several paths, three of which will be the main focus of the rest of this section. [newsprint, magazines, & books] First of all, programs in BASIC were made available inexpensively in cheaply produced newsprint magazines of the sort one might buy today to do crossword puzzles or play ken-ken. Little can be said about these material objects and how they cast might on the transmission of BASIC, except to say that the fact of their impermanence reflects the way were seen, by publishers and/or users, it is difficult to say. One can surmise that they were, relatively speaking, inexpensive and readily available at counters and newsstands. Since these are not the types of items most libraries would have collected and conserved over the decades, they are very difficult to find. By the 1970s, the practice of turning to electronics and computer magazines was common. Ziff-Davis’s Popular Electronics, launched in 1954, was perhaps the first broadly available computer magazine. It developed a strong following among computer specialists and hobbyists alike, and because of its success was only the first of Ziff-Davis’s magazines about computer technologies over the next five decades [Ziff-Davis filed for bankruptcy in 2008]. In the early 1970s the magazine’s format grew to letter-size (8.5 x 11 in), and the magazine’s tagline "World's Largest Selling Electronics Magazine" would grace its cover. Many claim that the image of the new Altair computer on the January 1975 issue of Popular Electronics triggered the age of home computing. Not even a decade later, in November 1982, Popular Electronics was renamed; under the name Computers & Electronics, the magazine reviewed hardware and software products.

    During that same decade, spurred by the growth of home computing as well as nurturing it, many other computer magazines came and went. Several, however, are worth mentioning here because they trafficked in BASIC and catered to BASIC learners and aficionados alike – namely Byte, Commodore Magazine, Creative Computing, Run, Rainbow, and Dr. DOBBS. These magazines, which themselves changed over the years, offer a window into the range of BASIC users and programs as well as reviews and discussion of new hardware and software that be and remain of interest to BASIC-using communities.

    Creative Computing was an early magazine in the world of micro-computing. Founded by David H. Ahl, who also wrote some ground-breaking books [later], Creative Computing focused on publishing for the home computer hobbyist; launched in 1974, it survived until 1985.

    Run was a monthly magazine published by IDG Communications that didn’t start publication until 1984 and devoted itself to all things Commodore. There was also a German edition on RUN.

    Rainbow Magazine was a monthly magazine for the TRS-80 Color Computer, and it was published from July 1981 to May 1993. Rainbow featured a Rainbow on Tape and Rainbow on Disk services to supplement the type-in programs the magazine offered. The magazines offered type-in programs, recipes, math games, etc.

    Byte was a monthly magazine with wide-ranging coverage that appeared first in September 1975 on the heels of the early personal computers manufactured and sold as kits. It survived under several owners until 1998. • Dr. DOBBS

    • Sinclair User (UK) – from April 1982 thru April 1993

    [More to come on magazines-- please feel free to add to these magazine entries. Question: does anyone know of any foreign magazines worth mentioning here besides Sinclair User? Or any foreign editions of any of these besides Run?]

    [More to come a whole chunk of writing about books dealing with BASIC]

    Programs 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 at least there is material evidence that programs were transmitted in this way, and people today can somehow relate to this practice because they are still invited to key in code snippets of different sorts that are printed in 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 with the world's great computer programs 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 to type into a friend's computer or one at school.

    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 perfection when he was near death, 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, or a machine, that he can perfectly remember documentation that he wrote -- and, as is dramatically revealed, he's also an extreme enough programmer that he can retype the code he and Liam developed together.

    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 also an ability that is awesome, desirable, and elite. At the same time, the story's treatment of the human body and mind as comptuerlike, 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.

    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?

    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. (Note: In both these studies, the programs were printed out and handed to subjects. None were shown programs on a screen.) 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)

    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. For instance, Shneiderman cites the famous paper on short-term memory, 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. The appearance of program variants that work identically but are written differently is consistent with studies on and theories of program memorization.

    Works Cited

    Anon. 1982. Commodore 64 User’s Guide. Wayne PA; Indianapolis, IN: Commodore Business Machines; Distributed by Howard W. Sams & Co. http://www.commodore.ca/manuals/c64_users_guide/c64-users_guide.htm.

    Brooks, Ruven. "Towards a theory of the comprehension of computer programs." International Journal of Man-Machine Studies 18. pp. 543-554. 1983.

    Doctorow, Cory. "0wnz0red." Salon.com. August 28, 2002.

    Kemeny, John G., and Thomas E. Kurtz. 1985. Back to BASIC: The History, Corruption, and Future of the Language. Addison-Wesley.

    Shneiderman, Ben. "Exploratory Experiments in Programmer Behavior." International Journal of Computer and Information Sciences, Vol. 5, No. 2., 1976, pp. 123-143.

    Widenbeck, Susan. "Beacons in computer program comprehension." International Journal of Man-Machine Studies 25. pp. 697-709. 1986.

    Personal tools