BASIC

Revision as of 11:51, 16 June 2011 (view source)

Nickm (Talk | contribs)

(→Altair BASIC, Micro-Soft, and Microcomputers)

← Older edit

Revision as of 12:32, 16 June 2011 (view source)

Nickm (Talk | contribs)

(→Dartmouth BASIC and Time-Sharing Minicomputers)

Newer edit →

Line 31:

BASIC was designed in other ways to help new programmers, with "error messages that were clear and friendly" and default options that would satisfy most users' needs (9). "If the expert needs something fancier," Kemeny and Kurtz declared, "let the expert do the extra work!" (11). And, BASIC was meant to be a true high-level language, so that programmers would not need any detailed knowledge of the specific hardware being used (9).

−

While BASIC didn't require that programmers put things in certain columns, there was a requirement that something be put at the beginning of each line: A line number, such as "10." This facilitated branching, of course; the GOTO and GOSUB statements refer to the line numbers where program flow should continue. But BASIC did not need line numbers for this purpose. Labels, such as those used in assembly, would have sufficed, and indeed they do suffice in later versions BASIC that do not use line numbers. The line number's real value is seen on a teletype or other print terminal, or in any environment where full-screen editing is not an option. Line numbers made it easy in those cases to delete existing lines; simply type the line number without any further instructions, and the line disappears. To correct a single existing line, it's possible to simply retype the line with the same line number.

+

While BASIC didn't require that programmers put things in certain columns, there was a requirement that something be put at the beginning of each line: A line number, such as "10." This facilitated branching, of course; the GOTO and GOSUB statements refer to the line numbers where program flow should continue. Although often associated with BASIC, GOTO did not originate with Kemeny and Kurtz's language. FORTRAN already had a GOTO statement, which was the basis for the one in BASIC (Kurtz p. 86). Before that, the unconditional branch was a feature of assembly and machine languages and did the same thing as GOTO.

+

While numbered lines were to some extent helpful for branching, BASIC did not actually need line numbers for this purpose. Labels, such as those used in assembly, would have sufficed, and indeed they do suffice in later versions BASIC that do not use line numbers. The line number's real value is seen on a teletype or other print terminal, or in any environment where full-screen editing is not an option. Line numbers made it easy in those cases to delete existing lines; simply type the line number without any further instructions, and the line disappears. To correct a single existing line, it's possible to simply retype 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 <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. It was an acknowledgement that the program is dynamic rather than fixed and perfect. The ''Commodore 64 User's Guide'' also 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).

From Maze

Revision as of 12:32, 16 June 2011

Views

Personal tools

Navigation

Search

Toolbox

@@ Line 31: / Line 31: @@
 BASIC was designed in other ways to help new programmers, with "error messages that were clear and friendly" and default options that would satisfy most users' needs (9). "If the expert needs something fancier," Kemeny and Kurtz declared, "let the expert do the extra work!" (11). And, BASIC was meant to be a true high-level language, so that programmers would not need any detailed knowledge of the specific hardware being used (9).
-While BASIC didn't require that programmers put things in certain columns, there was a requirement that something be put at the beginning of each line: A line number, such as "10." This facilitated branching, of course; the GOTO and GOSUB statements refer to the line numbers where program flow should continue. But BASIC did not need line numbers for this purpose. Labels, such as those used in assembly, would have sufficed, and indeed they do suffice in later versions BASIC that do not use line numbers. The line number's real value is seen on a teletype or other print terminal, or in any environment where full-screen editing is not an option. Line numbers made it easy in those cases to delete existing lines; simply type the line number without any further instructions, and the line disappears. To correct a single existing line, it's possible to simply retype the line with the same line number.
+While BASIC didn't require that programmers put things in certain columns, there was a requirement that something be put at the beginning of each line: A line number, such as "10." This facilitated branching, of course; the GOTO and GOSUB statements refer to the line numbers where program flow should continue. Although often associated with BASIC, GOTO did not originate with Kemeny and Kurtz's language. FORTRAN already had a GOTO statement, which was the basis for the one in BASIC (Kurtz p. 86). Before that, the unconditional branch was a feature of assembly and machine languages and did the same thing as GOTO.
+While numbered lines were to some extent helpful for branching, BASIC did not actually need line numbers for this purpose. Labels, such as those used in assembly, would have sufficed, and indeed they do suffice in later versions BASIC that do not use line numbers. The line number's real value is seen on a teletype or other print terminal, or in any environment where full-screen editing is not an option. Line numbers made it easy in those cases to delete existing lines; simply type the line number without any further instructions, and the line disappears. To correct a single existing line, it's possible to simply retype 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 <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. It was an acknowledgement that the program is dynamic rather than fixed and perfect. The ''Commodore 64 User's Guide'' also 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).