Why did BASIC use line numbers?

Question

Why did old BASICs (and maybe other languages) use line numbers as part of the source code?

I mean, what problems did it (try to) solve?

If you have already done some serious reseach effort, don't bury information about it inside of comments, edit your question accordingly. Moreover, Google took me directly here: http://stackoverflow.com/questions/541421/why-did-we-bother-with-line-numbers-at-all and here http://stackoverflow.com/questions/2435488/why-basic-had-numbered-lines — Doc Brown, Feb 10 '16 at 14:47
I'm voting to close this question as off-topic because the answer is [already on stackoverflow](http://stackoverflow.com/questions/541421/why-did-we-bother-with-line-numbers-at-all). — Andres F., Feb 10 '16 at 23:30
Applesoft BASIC was the first programming language I learned. I remember hearing that Pascal doesn have line numbers and going like "But how do I do a GOTO without line numbers? How is that supposed to work??" — Jens Schauder, Feb 11 '16 at 07:08
@DerMike: "obvious" is a dangerous words. It always relates to exactly one person on the world, if at all (person may die). To me, there is no obviousness of your research at all. — phresnel, Feb 11 '16 at 07:23
Funny, last time I checked, we were juding if the question was on topic basing on its content, not content of other sites(and presumably answers that lie there). — MatthewRock, Feb 11 '16 at 10:03
Simple: BASIC came with a line editor, and it needed the Line Number to know which line you were changing, inserting or deleting. There was also a special BASIC command to renumber all of the Lines. — RBarryYoung, Feb 11 '16 at 13:16
Incidentally, don't leave an infinite loop drawing lines randomly as a screensaver on an Acorn BBC. Mine went up in smoke (literally) when I dug it up for some nostalgia. — Knossos, Feb 12 '16 at 13:27
Basic, like Fortran, does not use line numbers, but labels. It is the editor that uses numbers to identify / store lines of text. In the case of Fortran, before line or screen editors where used, the labels were often used for numbering the punched cards so that the human programmer could keep them in order. — Roland, Feb 12 '16 at 09:42

score 132 · Accepted Answer · 2016-02-10T15:34:54.723

132

BASIC needs to be taken into context with its contemporary languages: early fortran, cobol and assembly.

Back when I was dabbling on 6502 assembly without labels, this meant that when you found that you needed to add an instruction somewhere in the middle of tightly packed code (I later added NOPs) you needed to go through and redo all of the jump addresses. This was time consuming.

Fortran was a line numbered based system that predated BASIC. In Fortran, columns 1-5 were a line number to be used for targets for branching. The key thing with Fortran was that the compilers tended to be a bit more intelligent than the BASIC interpreter and adding a few instructions was just a matter of punching some cards and putting them in the deck at the right place.

BASIC, on the other hand had to keep all of its instructions ordered. There wasn't much of a concept of a 'continuation of the previous line'. Instead, in Applesoft BASIC (one of the widely used dialects that I am familiar with and can find information on) each line in memory was represented as:

NN NN   TT TT   AA BB CC DD .. .. 00

It had two bytes for the address of the next line (NN NN). Two bytes for the line number of this line (TT TT), and then a list of tokens (AA BB CC DD .. ..) followed by the end of line marker (00). (This is from page 84-88 of Inside the Apple //e)

An important point to realize when looking at that memory representation is that the lines can be stored in memory out of order. The structure of memory was that of a linked list with a 'next line' pointer in the structure. This made it easy to add new lines between two lines - but you had to number each line for it to work properly.

Many times when working with BASIC, you were actually working in BASIC itself. In particular, a given string was either a line number and BASIC instructions, or a command to the basic interpreter to RUN or LIST. This made it easy to distinguish the code from the commands - all code starts with numbers.

These two pieces of information identifies why numbers were used - you can get a lot of information in 16 bits. String based labels would take much more space and are harder to order. Numbers are easy to work with, understandable, and easier to represent.

Later BASIC dialects where you weren't in the interpreter all the time were able to do away with the every line numbered and instead only needed to number the lines that were branch targets. In effect, labels.

edited Feb 10 '16 at 15:34

answered Feb 10 '16 at 15:04

3

Good gravy, I'd forgotten about the Mini Assembler. That [brings back memories](https://www.youtube.com/watch?v=yJp2TnKhnzY). – Blrfl Feb 10 '16 at 16:17
3

@Blrfl If memory serves... `] CALL -936` `* F666 G` `$ ...` Yep, FP basic to start with. – Feb 10 '16 at 16:47
1

There's a link to the FP source in [this answer](http://programmers.stackexchange.com/a/283413/20756) for your enjoyment. :-) – Blrfl Feb 10 '16 at 18:03
1

It also made the REPL experience significantly easier to write. – lzcd Feb 11 '16 at 01:52
This is incorrect. The reason that most early BASIC's (unlike FORTRAN) required line numbers for every line was solely because most early BASIC's were Interpreters that came with built-in "interactive" Line Editors, which needed the line number of the statement to be edited. – RBarryYoung Feb 11 '16 at 13:20
@RBarryYoung if your answer is correct, shouldn't it be an answer rather than a comment? – Elder Geek Feb 11 '16 at 14:26
@RBarryYoung The REPL environment of many required a distinction between delayed execution code and commands to be executed now. The way this was implemented was "if it starts with a number, store it; else run it". Thus, all lines in a delayed execution block of code needed line numbers. This had nothing to do with line editors (for example, AppleSoft didn't have a line editor). The set of design choices (data structure for memory, how the REPL worked, how the program was stored to and loaded from disk) required line numbers for this to work in an reasonable and consistent way. – Feb 11 '16 at 14:32
4

No, that *was* the line editor. Commands were identified by not having line numbers. Statements were preceded by line numbers to indicate both that they were statements and to indicate were they went and/or what line they overwrote. That was the built-in line editor part of BASIC, it wasn't a separate tool or environment. – RBarryYoung Feb 11 '16 at 15:38
@ElderGeek it already is, see the answer here by JacquesB, plus this answer to the same question from years ago: http://stackoverflow.com/a/541447/109122 – RBarryYoung Feb 11 '16 at 15:41
3

@RBarryYoung `] PRINT "FOO"` was run by the BASIC interpreter immediately. It is a statement. If you wanted to run it later, you would do `] 10 PRINT "FOO"` and then `] RUN`. In the AppleSoft BASIC environment, every BASIC statement could be run immediately or delayed - there were only a very few commands that were provided by DOS that were not valid BASIC statements. The differentiation between a statement now and a statement later was the line number. You could also modify a delayed statement by reentering the corresponding line number. You could also put multiple statements on one line: `:` – Feb 11 '16 at 15:45
1

Yes, you are talking about AppleSoft BASIC, which came out some ten years after many versions of BASIC were commercially available. AppleSoft BASIC required Line Numbers because all preceeding commercially available versions of BASIC required them. The question was not "How does AppleSoft work with Line Numbers", it was "Why did BASIC use line numbers?" and the reason, was for the line editors. – RBarryYoung Feb 11 '16 at 15:49
@RBarryYoung I have difficulty finding the information on the actual representation in memory of any of the other earlier dialects of BASIC. They all had the same requirement. The key point being you needed to be able to modify the memory structure and address it from the REPL. I will also note that your statements about the editor and my statements about the memory structure *require* the other to be true. – Feb 11 '16 at 15:59
4

As noted in the Wikipedia article (https://en.wikipedia.org/wiki/Dartmouth_BASIC) "*DTSS (Dartmouth Time Sharing System) implemented an early ... interactive command line interface. ... Any line beginning with a line number, was added to the program, replacing any previously stored line with the same number; anything else was assumed to be a DTSS command and immediately executed. ... This method of editing was necessary due to use of teleprinters as the terminal units for the Dartmouth Timesharing system.*" – RBarryYoung Feb 11 '16 at 15:59
The previous comment also highlights the motivating factor for this approach: Line printers and character-cell terminals in a time-sharing environment. Until the advent of video editors, this was by far the easiest way to program in those environments. – RBarryYoung Feb 11 '16 at 16:02
1

@RBarryYoung [DTSS](https://en.wikipedia.org/wiki/Dartmouth_Time_Sharing_System) also supported Fortran (with optional line numbering) and Algol (with no line numbering). Clearly, DTS didn't *need* line numbers for the languages that it supported. However, the structure of a BASIC program, with line numbers facilitated a particular form of editing. That type of editing required a particular memory representation of the code. That memory representation of the code, allowed that form of editing. The two are mutually dependent. – Feb 11 '16 at 16:08
For most languages the Line Editor *added* line numbers as a left-hand adjunct to the listings. One of the innovations Kemeny and Kurtz made with BASIC was to *incorporate* the line numbers into the language. I have heard them say it. AFAIK, there is no support from K+K or anyone else for the claim that BASIC's line numbers were motivated by BASIC's memory management, rather just the opposite. – RBarryYoung Feb 11 '16 at 16:24
1

@RBarryYoung but you didn't *need* to have line numbers to have a language that was edited by teletype. Rather that having line numbers be part of the memory representation of the program made editing via teletype easier. But that isn't a requirement. It could have been done as with Fortran where only branch targets and labels needed to be numbered. However, that makes it a bit more awkward to insert text between two lines. Storing the program as a linked list indexed by line number made it easier for teletypes to edit the code (than doing the same in Fortran). – Feb 11 '16 at 16:30
3

Again, there is just no support for the claim that BASIC's line number were motivated by it's memory management. Even then, design drove development, not the other way around. I started my career during this era and wrote many FORTRAN, and COBOL and BASIC programs. FORTRAN and COBOL *could* be edited with a line editor, but it was hard and card decks were preferred (which is what they were designed for). OTOH, we virtually never used cards for BASIC, as the line editor builtin to the BASIC.exe made it much easier to write and edit it on a teletype or CRT, which, again *it* was designed for. – RBarryYoung Feb 12 '16 at 16:06
3

Oh my God. For the younger ones this stuff really puts the simplicity of modern stuff (Python for example) into perspective. – a06e Feb 14 '16 at 23:23
@becko arguably, while some parts of this were a bit more complex (line numbers were a pain and try using `ed` for a day), the *language* was quite a bit simpler. You will find things like [basic on a chip](http://www.coridiumcorp.com/prod-specs1.html) now because it is such a simple system - 6M lines/second? 32k flash? 4k ram? 20k user flash space? Those *huge* when you're talking about BASIC. There is value in the language and understanding how its interpreter ran. The line numbers - they are addressable labels. – Feb 15 '16 at 00:01
@becko Absolutely. If you wanted to program back then you had to *really* want it bad. – RBarryYoung Apr 05 '18 at 22:29
You had to work for it, but it was a lot more special. The 50 pound desktop unit, or 20 pound home console unit... key clicks, green screens (or 4 or 16 color graphics if you were lucky)... loading software from tapes or 5.25" floppies. But you were doing something previously only available to scientists, business people at enormous bluechip corporations, and a lucky few with time-share access at research institutions. You were reading Far Side cartoons and getting the inside jokes. It was amazing, even if it was hunting the wumpus or writing personal contact book programs. Normalized today. – DavidO Sep 03 '19 at 02:45
I downvoted this and can tell you why: the NN NN described as for the address of the next instruction is NOT what the OP is asking about, since almost no one programming in BASIC would know at what address a line would be stored. It doesn't make sense to have the programmer type in the address of the NEXT line when they haven't finished typing in the current line. Line numbers input by programmers were for sequencing the interpretation of the set of lines. The standard of 'every 10' was simply to reserve room for simple edits later without requiring a major revisions. – Kelly S. French Mar 06 '23 at 18:54

score 52 · Answer 2 · answered Feb 10 '16 at 15:20

52

On early microcomputers editing was line based. You couldn't just move freely around in the source code and edit. You had a single line at the bottom of the screen where you could type commands and enter code. The rest of the screen was read-only code-listings and command output. If you wanted to edit say line 90 in the program you wrote "EDIT 90", and the contents of line 90 entered the single-line edit buffer. When you had edited the line you hit enter, and the program listing was updated. So you needed line numbers in order to be able to edit the program.

When code editors became more advanced and allowed you to move the cursor around in the code listing you didn't need line numbers anymore.

answered Feb 10 '16 at 15:20

JacquesB

57,310
21
127
176

40

*Editing* a line? Luxury! The first BASICs I used made you re-type the whole line. Which really sucked when you had to renumber a subroutine. – TMN Feb 10 '16 at 16:58
49

Screen? What screen? In my first Basic, the "screen" was a roll of paper. – ddyer Feb 10 '16 at 20:05
2

+1 ddyer. For me, it was an ASR33 Teletype, and a Bell 101 modem. – Solomon Slow Feb 10 '16 at 20:56
1

All true, but the lines in a BASIC program had line numbers that were part of the program text, not lines numbered by the editor. – Caleb Feb 10 '16 at 21:51
It's called "making lemonade". Since line numbers were the sensible way to edit, they were also make elements of the language. Same as in Fortran, except the line numbers were optional in Fortran. – ddyer Feb 11 '16 at 00:38
20

@ddyer: I used to dream of having a roll of paper! All _we_ had was a bunch of electrodes. In the evening when the work was supposed to be done, we would have to align ourselves in a row and observe who got electrocuted, to see if the program worked correctly. ... — Seriously, I'm awestruck that people actually managed to write working programs back in those days. – leftaroundabout Feb 11 '16 at 10:14
27

Electricity! Bloody luxury. We used to chisel our commands out in granite – Michael Durrant Feb 11 '16 at 10:46
1

This is the correct answer. – RBarryYoung Feb 11 '16 at 13:21
@TMN "retyping the whole line" *was* called "editing" at that time. (because it was a "Line Editor" and not a "Character Editor"). – RBarryYoung Feb 11 '16 at 13:23
11

@TMN & ddyer OK, you both know where this is heading, right...? ;-D ==> http://dilbert.com/strip/1992-09-08 ==> https://imgs.xkcd.com/comics/real_programmers.png – Baard Kopperud Feb 11 '16 at 13:47
3

Even though everyone is joking, the teletype and roll of paper was something I have actually encountered. – gnasher729 Feb 11 '16 at 20:41
I grew up with phones that had a handle on the side. I used to use the telex machine at my dad's office. I used to use Morse code (or semblance thereof) to debug Intel SBCs that had a single LED on board. I remember when we got our first fanfold dot matrix ALL CAPS printer to connect to our PET. Computers were sooo much more fun then. And BASIC was awesome, despite the lack of functions as first class objects and continuation. But try doing PEEK and POKE on anything nowadays. – copper.hat Feb 13 '16 at 10:10
@copper.hat `POKE address, value` -> `*((char*)address) = value;` – Mr Lister Feb 13 '16 at 13:40
1

@MrLister: Not quite the same as typing in a suitable peek command and watching characters appear on the screen, or turning on the cassette recorder :-). – copper.hat Feb 13 '16 at 17:21
@copper.hat Or turning on HGR, or making a sound. I know. I've been there! – Mr Lister Feb 13 '16 at 17:25
1

@MrLister: I remember the excitement. Unfortunately that sense of discovery (of the connection between the software and hardware) is gone (Raspberry Pis are great, but just to turn on a GPIO I need a 6 line Python program, or similar. With the PET, I just turned it on and typed peek. Awesome). – copper.hat Feb 13 '16 at 17:34
For my first programs, I blackened squares on an optically read "punch" card with a pencil. Inserting a line simply meant coloring in the boxes of another card. I was grateful for the suggestion to number my cards with an initial interval of 10, so I would be able to insert up to 9 lines... And yes, you could just add the out-of-order card at the end of the stack and read the whole stack back into the computer (which was a 15 minute bike ride from our school, and could be used only once a week. Needed to manually debug your program before you went...) – Floris Feb 13 '16 at 17:51
I remember trying to find the power switch. 3D0G was helpful, if that failed, just type 0G. If you had POKEd the thing into oblivion (usually producing a plaintive ? REDO FROM START ?) you had to cold boot. On the PDP-11, you could type A=SYS(-7). Once. Then the teacher would not let you use it anymore. Then *he* had to remember where the power switch was. And so it goes. – Feb 14 '16 at 02:40

hyde · Answer 3 · 2016-02-12T17:53:41.180

If you are thinking of BASIC dialects of the 8-bit home microcomputers of 80's, then those computers did not have text editors (unless you bought some word processor application). There was no way to have the entire BASIC program source code "open in an editor", like you would have when programming today. Programmer wouldn't even think about the program as a source code file, or text, really.

Example problem

So, lets say you have a simple program without line numbers in your head:

FOR I=1 TO 42
PRINT I
NEXT I

You boot up your computer. You have a prompt "ready" or something like that, and cursor sitting in next line. This is much like today's REPL environments of different scripting languages, though not really as strictly line based, more like screen based. So not quite like REPLs of today, but close.

Now if you start entering the program, you might get error after first line, because BASIC interpreter tries to immediately execute (and forget) it, and it doesn't make sense without NEXT to end the loop. This is not text editor where you edit text, this is where you give commands to the computer!

Partial solution

So you need some way to say, this is program line, store it! You could have a special command or just a symbol telling that hey, this is program line, store it. Let's imagine this:

#FOR I=1 TO 42
#PRINT I
#NEXT I

Ok, now our imaginary BASIC interpreter stored the program and you can run it. But now you want to edit the PRINT line. How do you do it? You are not in a text editor, you can't just move cursor to the line and edit it. Or you want to add another line like LET COUNT=COUNT+1 in the loop. How do you indicate where the new line should be inserted?

Working solution

Line numbers solve this in a very easy, if rather klunky way. If you enter a program line with a number that already exists, the old line gets replaced. Now the screen-based REPL environment becomes useful, because you can just move cursor to program listing on screen, edit the line on screen and press ENTER to store it. This seems like you are editing the line, when in fact you are editing text on screen and then replacing the entire line with new one from the screen. Also, inserting new lines becomes easy if you leave unused numbers in between. To demonstrate:

10 FOR I=1 TO 42
20 PRINT I
30 NEXT I

After re-entering line 20 with changes, and adding new lines, it could be

5 LET COUNT=0
10 FOR I=1 TO 42
20 PRINT "Index", I
25 LET COUNT=COUNT+1
30 NEXT I

Conclusion

Other answers explain how line numbers came to be. I'm trying to cover here, why the line numbers survived as long as they did, how they kept solving a real-world problem: They offered a way to do the actual programming without a real editor, in a very simple way. Once proper, easy-to-use full-screen text editors became the mainstream way to edit code, both with hardware limitations disappearing and when inertia of people adapting new things was overcome, then line number based BASIC dialects quite quickly disappeared from use, because the core usability problem they solved was no longer an issue.

You nailed it. Having a multi-line screen rather than just a printing tty or single line makes it easier, but without a source file concept it's still line oriented. — JDługosz, Feb 11 '16 at 07:16
The fact that the system is an 8-bit architecture isn't really the limiting factor, though. Now, the fact that said system might have only a few kilobytes of RAM and a handful of kilobytes of ROM, and possibly even no permanent storage (if your casette tape recorder broke)... — user, Feb 11 '16 at 20:37
@LưuVĩnhPhúc Well, there are plenty of emulators for running "the real thing", such as almost any 8-bit home computer, or MSDOS and its GWBASIC with dosbox. Just as an example, you could get one of the many C64 emulators, and then Google to find [its User's Guide as PDF](http://www.mocagh.org/softguide/c64user.pdf) :-) — hyde, Feb 12 '16 at 15:31
Exactly right. But note that the methods you describe actually predate microcomputers. I learned to edit code that way on a PDP-11 minicomputer. (A minicomputer was a low end computer widely used before the invention of microprocessors.) — Isaac Rabinovitch, Feb 16 '18 at 18:30
@phuclv - Hard to imagine coding without a text editor now. At the time, hard to imagine the inconvenience of having to use a text editor, save it, and compile it before it could be run ... and that's really what came next to the PC world; Pascal and C. Both compiled languages, both freely editable with a text editor, both definitely not a programming environment in and of themselves (BASIC was both programming environment and runtime environment). Pascal was my next language, and in many ways quite liberating. Definitely more powerful. But in other ways, a little less thrilling. — DavidO, Sep 03 '19 at 02:55

score 18 · Answer 4 · answered Feb 10 '16 at 20:09

18

In the place and era when Basic was developed, the best available I/O device was a teletype. Editing a program was done by printing (on paper) a listing of the whole program, or the interesting part of it, and then typing replacement lines with line numbers.

That's also why the default line numbering was by 10, so there would unused numbers between existing lines.

answered Feb 10 '16 at 20:09

ddyer

4,060
15
18

1

Actually, card readers (accompanied by keypunches) and line printer were better I/O devices than a teleprinter, but teleprinters were a lot cheaper. – supercat Feb 13 '16 at 03:08
Line numbering by 10 was a de facto standard, not a rigorous requirement. And many BASICs had a '`ren`' command, to renumber. A typical invocation was `ren 10, 10` (renumber starting at ten, incrementing by ten -- the default behavior if one just typed `ren`. The `goto` and `gosub` and `then (linenumber)` commands would be automatically updated. But this was definitely not available in the earliest BASICs. But IIRC, was available in Apple Integer Basic, Applesoft FP basic, TI Basic/Extended Basic, MS Basic / GW Basic, etc. – DavidO Sep 03 '19 at 02:59

score 13 · Answer 5 · answered Feb 10 '16 at 15:08

13

"Line numbers" means a few different things.

First of all, keep in mind that the concept of "lines" hasn't been around forever. Many programming languages in this era used punched cards, and having sequence numbers (usually in the last few columns of the card) helped you recover your deck in the proper order if you dropped it, or something awful happened in the card reader. There were machines to do this automatically.

Line numbers for use as targets of GOTO statements is a totally different concept. In FORTRAN IV, they were optional, and preceded the statement (in columns 1-5). In addition to being easier to implement than free-form labels, there was also the concept of the computed and assigned GOTO, which allowed you to jump to an arbitrary line number. This was something most modern programming languages don't have (although switch statements come close), but was a familiar trick to assembler programmers.

BASIC was derived from FORTRAN, and intended to be simpler to implement and to understand, so forcing every "line" to have a line number (both for sequencing and as the target of GOTO/GOSUB statements) was probably a design decision made for that reason.

answered Feb 10 '16 at 15:08

Mike Harris

572
3
12

2

Ah, computed and assigned gotos. Memories of arrays of label variables in PL/1, looping through one array to find a match and then using that matches array index as the index in the array of label variables to do a goto to. Or Cobol altered gotos. And neither using line numbers! BBC basic had a renumber statement that was very useful. – Kickstart Feb 11 '16 at 10:31
1

GCC allows computed GOTOs as an extension (although not with a line number directly of course) - you can do stuff like `goto array_of_labels[some_computation()];` – user253751 Feb 11 '16 at 21:34
Minor: FORTRAN required labels for targets of `GOTO` (or `ASSIGN`) and the original aka arithmetic aka threeway `IF`, and (rarely used) alternate returns in `CALL`, and sort-of-targets (arguably delimiters) of `DO`, and `FORMAT` statements. On other statements they were optional. – dave_thompson_085 Feb 12 '16 at 12:28
Some BASICs (e.g., Atari's) even allowed arbitrary numeric expressions to be used in GOTO statements. So, with a proper line numbering convention, you could write `GOTO 1000+N*100` to emulate a `switch` statement. – dan04 Feb 26 '16 at 23:39

score 6 · Answer 6 · answered Feb 10 '16 at 14:51

6

I started programming in COBOL which used line numbers in columns 1-6 of each line. Because there were no IDE's in the 1970s everything was done via punched cards and the line number was used to identify which lines in the original source were to be replaced and which new lines added. We used to increment line numbers by 100 to give us room to add in more lines.

answered Feb 10 '16 at 14:51

Keith Miller

169
1
6

14

COBOL did not use those line numbers. They were strictly a convenience, so that when some poor schlub dropped his deck, and cards went everywhere, he could just gather them up and run them through the card sorter to get them back into the correct order. You were NOT required to punch the line numbers into the cards. (Students didn't. Production shops did.) – John R. Strohm Feb 10 '16 at 15:41

score 5 · Answer 7 · answered Feb 10 '16 at 16:20

5

BASIC came about later than FORTRAN, in the line-terminal era. It featured a read-exe-print-loop environment that was more interactive than a deck of cards.

I learned to program, in BASIC, on a one line display that held 24 characters. Line numbers were a natural way to specify where you wanted a line to go, whether editing one or inserting between others.

I really can't imagine how else you would do it.

answered Feb 10 '16 at 16:20

JDługosz

568
2
9

2

this doesn't seem to offer anything substantial over points made and explained in prior 4 answers – gnat Feb 10 '16 at 16:33
2

That makes it bad? I think Jaques didn't really cover the essence of one-line editing with respect to inserting lines and mentally tracking the code. – JDługosz Feb 10 '16 at 17:11
BASIC was often used with punch cards – Ian Feb 10 '16 at 18:11
1

@jameslarge Do I miss that point in the paragraph beginning with "Many times when working with BASIC..."? I also hesitate to call BASIC the operating system. That was DOS. And DOS didn't need BASIC, its just what you had most of the time to work in. – Feb 10 '16 at 21:42
2

@Ian while that's true, it was *designed* for a system that used teletypes for io (the Dartmouth Time Sharing System). – Jules Feb 10 '16 at 22:12
3

@MichaelT, Oops! I'll retract half of my comment, but I'll stand by the part about BASIC being the OS on some computers. I'm thinking; Apple ][, TI 99/4, IBM 5100, HP 9830a, Compucolor 8001, TRS-80 Model 1, Comodore Vic20, Sinclair ZX80, and others. All booted up into BASIC from ROM. Some had an _optional_ operating system that could be loaded from an audio casette or, from floppy disk if you paid the extra $$ for a floppy drive. – Solomon Slow Feb 11 '16 at 00:21
Long before the Apple ][ etc. came on the scene, the HP-2000 had time-sharing BASIC as its sole operating system. – supercat Feb 13 '16 at 03:09

score 1 · Answer 8 · answered Feb 12 '16 at 15:51

One point no one's mentioned yet is that it's easier for beginners to reason about program flow where the branch targets are explicit. So rather than having to match (possibly nested) BEGIN/END statements (or whatever block delimiters were used), it was pretty obvious where the control flow went. This was probably useful given BASIC's target audience (it is the Beginner's All-purpose Symbolic Instruction Code, after all).

score 1 · Answer 9 · answered Aug 25 '16 at 02:09

Dartmouth Time Sharing System used a teletype interface. Thus it used a command based interface. Originally, line numbers were just used as a means to edit the program. You could insert, replace, or delete by using a line number. It does not appear that the early version used line numbers for goto statements, but this was a later addition to the language.

Why did BASIC use line numbers?

9 Answers9

Example problem

Partial solution

Working solution

More problems we just solved

Conclusion