4 ms·

Were line numbers in old BASIC games actually helpful, or just extra typing?

femto 1y ago
They were required for most early BASIC interpreters. They acted as a label for goto statements and determined the listing/execution order. From memory, the TRS-80 (and similar) would immediately execute a statement without a line number, but would store a statement with a line number.
- a_e_k 1y ago
  They were also how you edited your program in the absence of a coding editor. You'd type LIST to see your current program, type a new line with the same number to replace an existing line, or a new line with a new number to insert it numerically, etc.
  - femto 1y ago
    And it was an absolute pain if you had to insert a new statement, but didn't have enough space left between line numbers. You had to retype the offending lines with new line numbers.
    - musicale 1y ago
      Dartmouth BASIC had a renumber command. I believe that line renumbering commands and/or utilities were commonly available for microcomputer BASICs as well.
      - femto 1y ago
        Some BASICs had a RENUM command. They were a bit of a pain as well. As you wrote your program you got to know which line numbers were associated with which statements. Doing a RENUM meant having to relearn the "meaning" of each line number. I'm pretty sure my VZ-200 didn't have the RENUM command.
      - michaelcampbell 1y ago
        Sadly Atari BASIC did not. I can't recall if the Apple ][ BASIC had it built in, or if Beagle Brothers utility software could do it, but it was possible somehow.
      - mrandish 1y ago
        Yes, most Microsoft ROM BASICs at least 8K in size had the renum command. It was still a pain because you had to figure out the start, end and skip values.
    - ahonhn 1y ago
      Common practice was to increment line numbers by 10 instead of 1. Would give a bit of wiggle room to add more lines in later without having to renumber everything else.
  - musicale 1y ago
    Dartmouth BASIC was designed for teletype-style, hard-copy printing terminals, rather than video displays. Conveniently your whole session was printed out, so you could take your email and program listing home with you. Line-by line editing was practical for printing terminals, and line-by-line I/O scaled well across multiple terminals on a timesharing system. Line editing also worked well on microcomputers with cursor movement (like the C64) - you could edit code in place just by overtyping and hitting "return" for the appropriate line. On a slightly unrelated note, teletypes date back to the 19th century telegraph (and typewriter) era. https://en.wikipedia.org/wiki/Teleprinter https://en.wikipedia.org/wiki/Teleprinter
    - genewitch 1y ago
      And still exist and are heavily used today, RTTY is built into most HF radios, and most militaries still use radio teletype, but encrypted and often at a different bandwidth. AX.25 and qpsk didn't manage to replace it.
- fifticon 1y ago
  To elaborate on that: They were the handle on the code lines, for anything. You would often use the line number to either edit a given line number, or to remove it. 'Clever' people would even do mis-guided arithmetic on them, e.g. GOTO MenuChoiceNum\*100 + 1000 GOSUB MenuChoiceNum\*100 + 1000
  - codr7 1y ago
    Wow, it hurts to imagine maintaining and evolving that code :)
    - michaelcampbell 1y ago
      Fortran's had computed goto's since... at least '77 version. Fun times, those.
      - pklausler 1y ago
        Fortran has never had a GOTO to a computed label number like this.
jamalaramala 1y ago
They were essential for branching with GOTO and GOSUB. Example: 10 PRINT "HELLO "; 20 GOTO 10 This would create an infinite loop that you could break with Ctrl+C. You could then type: 15 PRINT "WORLD "; And when you listed the source code (with the command LIST) you would see: 10 PRINT "HELLO "; 15 PRINT "WORLD "; 20 GOTO 10
mrandish 1y ago
Well, since most 8-bit micros with ROM BASIC actually started up in BASIC, any BASIC you wrote without a line number executed immediately (and wasn't saved). So before you even got to goto and gosub labels, line numbers were useful for that.

They were required for most early BASIC interpreters. They acted as a label for goto statements and determined the listing/execution order. From memory, the TRS-80 (and similar) would immediately execute a statement without a line number, but would store a statement with a line number.

a_e_k 1y ago
They were also how you edited your program in the absence of a coding editor. You'd type LIST to see your current program, type a new line with the same number to replace an existing line, or a new line with a new number to insert it numerically, etc.
- femto 1y ago
  And it was an absolute pain if you had to insert a new statement, but didn't have enough space left between line numbers. You had to retype the offending lines with new line numbers.
  - musicale 1y ago
    Dartmouth BASIC had a renumber command. I believe that line renumbering commands and/or utilities were commonly available for microcomputer BASICs as well.
    - femto 1y ago
      Some BASICs had a RENUM command. They were a bit of a pain as well. As you wrote your program you got to know which line numbers were associated with which statements. Doing a RENUM meant having to relearn the "meaning" of each line number. I'm pretty sure my VZ-200 didn't have the RENUM command.
    - michaelcampbell 1y ago
      Sadly Atari BASIC did not. I can't recall if the Apple ][ BASIC had it built in, or if Beagle Brothers utility software could do it, but it was possible somehow.
    - mrandish 1y ago
      Yes, most Microsoft ROM BASICs at least 8K in size had the renum command. It was still a pain because you had to figure out the start, end and skip values.
  - ahonhn 1y ago
    Common practice was to increment line numbers by 10 instead of 1. Would give a bit of wiggle room to add more lines in later without having to renumber everything else.
- musicale 1y ago
  Dartmouth BASIC was designed for teletype-style, hard-copy printing terminals, rather than video displays. Conveniently your whole session was printed out, so you could take your email and program listing home with you. Line-by line editing was practical for printing terminals, and line-by-line I/O scaled well across multiple terminals on a timesharing system. Line editing also worked well on microcomputers with cursor movement (like the C64) - you could edit code in place just by overtyping and hitting "return" for the appropriate line. On a slightly unrelated note, teletypes date back to the 19th century telegraph (and typewriter) era. https://en.wikipedia.org/wiki/Teleprinter https://en.wikipedia.org/wiki/Teleprinter
  - genewitch 1y ago
    And still exist and are heavily used today, RTTY is built into most HF radios, and most militaries still use radio teletype, but encrypted and often at a different bandwidth. AX.25 and qpsk didn't manage to replace it.
fifticon 1y ago
To elaborate on that: They were the handle on the code lines, for anything. You would often use the line number to either edit a given line number, or to remove it. 'Clever' people would even do mis-guided arithmetic on them, e.g. GOTO MenuChoiceNum\*100 + 1000 GOSUB MenuChoiceNum\*100 + 1000
- codr7 1y ago
  Wow, it hurts to imagine maintaining and evolving that code :)
  - michaelcampbell 1y ago
    Fortran's had computed goto's since... at least '77 version. Fun times, those.
    - pklausler 1y ago
      Fortran has never had a GOTO to a computed label number like this.

jamalaramala 1y ago

They were essential for branching with GOTO and GOSUB. Example: 10 PRINT "HELLO "; 20 GOTO 10 This would create an infinite loop that you could break with Ctrl+C. You could then type: 15 PRINT "WORLD "; And when you listed the source code (with the command LIST) you would see: 10 PRINT "HELLO "; 15 PRINT "WORLD "; 20 GOTO 10

mrandish 1y ago

Well, since most 8-bit micros with ROM BASIC actually started up in BASIC, any BASIC you wrote without a line number executed immediately (and wasn't saved). So before you even got to goto and gosub labels, line numbers were useful for that.