Hacker News Reader

Comment by sudofoo | Hacker News Reader

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

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

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.

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.

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.

Dartmouth BASIC had a renumber command. I believe that line renumbering commands and/or utilities were commonly available for microcomputer BASICs as well.

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.

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.

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.

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.

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

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.

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

Wow, it hurts to imagine maintaining and evolving that code :)

Fortran's had computed goto's since... at least '77 version. Fun times, those.

Fortran has never had a GOTO to a computed label number like this.

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.

Reply on news.ycombinator.com