BASIC

In 1962, change was sweeping through the remote Dartmouth campus. Time Magazine noted late that year, in article that declared the college was coming "out of the woods," that the school had built a major new arts center and that John Kemeny, who had made full professor at age 27, had built "the best college math department in the country." [http://www.time.com/time/magazine/article/0,9171,829487-1,00.html] The year, Kemeny and his colleague Thomas Kurtz had started developing a time-sharing system and a programming language to allow all students at Dartmouth -- not just those studying math, science, or engineering -- to learn how to program.

The creators of BASIC sought to create a language that novices could start using within minutes; 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 meant to be a true high-level language, demanding no knowledge of hardware specifics (9).

Version 1 of Dartmouth 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 cards, prepared on a keypunch and submitted to the computer. Multiple programs would be fed 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. [I don't see how replacing one line with another is any harder or easier than punching another card. It seems to me to be an identical process: one occurs on a Teletype, one occurs on a keypunch machine. A card is one line long. -nm]

The concept of line numbers was so unconventional at the time [Not true -- Fortran has line numbers. This information is just providing a clear specification so that others can reimplement BASIC. -nm] 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. [Fortran's came at the end of the line, columns 73-80. -nm] 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. [Line numbers seems to be important because of Teletypes/print terminals. If you have a screen editor, you don't need them. Witness QBasic and Visual Basic. -nm]

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 <ins>not</ins> 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. [Very good. We should quote other sources that suggest this practice. There are many. -nm]

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. [We're at Dartmouth in 1964 here; I don't think this is the time to talk about the skipping of line 30 in 1982 in the C64 User's Guide. -nm] 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--

--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. [All useful points, but let's not mention them in the context of 1964 Dartmouth. -nm]

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). [This is my point too ... -nm] 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.