Why did BASIC use line numbers instead of a full screen editor?

The first version of Microsoft BASIC was written for the MITS Altair 8800 – which didn't come with any graphics hardware, it was normally used over a serial port, from a teletype. Given a serial port talking to a teletype, full-screen editing is impossible.

Microsoft went on to port their BASIC to more platforms, many of which were capable of full-screen editing, yet they kept with the line-oriented interface–why? It was a lowest common denominator which worked across all hardware and was trivial to bring up on a new hardware platform or operating system–full screen editing would have required a lot more platform-specific code to be written, and would have been more affected by differences in capabilities between different platforms (screen sizes/etc).

BASIC wasn't invented in the 1980s: it was just used by PCs because it was already popular and easy to implement. Dartmouth BASIC was introduced in 1964, and it and DOPE (its immediate predecessor) were heavily derivative of FORTRAN; and BASIC was meant to run on teletypes. FORTRAN had line numbers and GOTO; and likewise BASIC did.

> Home computers in the early 80s were certainly capable of providing responsive full screen editing

Not exactly. Home computers leveraged televisions; often by generating radio signals (as opposed to direct video input).

The quality was awful. You couldn't rely on the screen to do much better than 320 X 240.

Also, in those days, most of us used 300-baud VT100 terminals, which were VGA (640 X 480). Not much room for chrome, and long text and fancy layout was painful.

The displays were ASCII-driven. Basically the precursor to Emacs/Vi.

Also, as was pointed out in another comment, Structured Programming was still in the future. If you were lucky, you had GOTO.

Line numbers didn't use up characters. They could be inferred. Memory was not cheap. It was also very limited. Every character (including comments), used up memory, and impacted performance. Variables had names like A1, A2, etc.

It was real fun, reading legacy code...

You kids don't know how good ya got it. Back in my day, we had to use a morse code keypad for data entry...

Get off my lawn...

Another reason: BASIC had a GOTO statement to change program flow to any point in the code. There was no idea of nested blocks of code that executed conditionally. The GOSUB directive was only useful in some situations.

GOTO needed somewhere to jump to and the easiest thing to delineate was a line number.

QuickBasic (1985) apparently did not need line numbers: "Although still supported in QuickBASIC, line numbers became optional."

- https://www.wikiwand.com/en/QuickBASIC

And BASIC itself was developed in 1963, when full screen editors may not have been as feasible.

- https://www.wikiwand.com/en/BASIC

It cost RAM to have a screen editor. A line editing routine is compact, saves a lot of bytes over making something that can scroll, copy-paste etc. The point of a built-in BASIC was that it was complete as-is and could run programs instantly. Thus while many languages for microcomputers used a batch compilation model and could do away with bookkeeping, BASIC was always slimmed to hit a nice small size and leave more room for user code.

It wasn't invented for home computers, it was invented for line printer terminals, where "line numbers" and the ability to edit/insert that gave was a real improvement.

As many people have noted, the reasons are primarily historical:

1. BASIC was invented in the 1960s and supported the "teletype" style printing terminals of that era. Line oriented operation also enabled efficient multiuser/timesharing operation. (BASIC's simplicity, compactness and low resource requirements translated well to early 8- and 16-bit systems.)

2. BASIC traditionally used line numbers as GOTO/GOSUB targets.

3. Bill Gates' original Microsoft BASIC and (Allison et al.'s) Tiny BASIC, which fit in as little as 8KB and 2KB respectively, were the basis or inspiration for many 8-bit BASIC implementations. Both used line numbers for compatibility with Dartmouth BASIC and for line editing on printing terminals and serial CRTs that didn't support cursor positioning. For example, Microsoft/Altair BASIC worked with printing terminals, and Apple (Integer) BASIC for the Apple I worked with a CRT console that (afaik) didn't support cursor positioning.

That being said:

1. On systems like the C64 you can move the cursor around on screen, getting a sort of "screen editor" functionality although technically it is still a line editor.

2. As you note, there is no technical reason why labels rather than line numbers couldn't be used, and several 8- and 16-bit BASIC versions supported them; line numbers were optional in implementations such as Digital Research CBASIC or Microsoft QuickBASIC.

Memory constraints. BASIC will run in 4 to 8 Kbyte (4000 to 8000) ROM. That budget was for editor, SAVE/LOAD,interpreter and overhead functions. The goal is to make the interpreter fast!

And, these were pre-IBM PC systems. (apple, radio shack 8 bit systems, many others).

Well back in the day… I did my Basic programming on a real Teletype Terminal (not an TTY screen) connected via an acoustic coupler running at 300 baud to a Honeywell timesharing system and saved/loaded programs via punch paper tape on the mid 70s.

I’m on the floor (laughing).

Most computer labs had punch card stations and paper terminals when BASIC was created.

You often used LIST to see your program and edited it by adding, removing, replacing line numbers.

Later on DEC terminals we had an editor named TECO that allowed you to do search and replace, inserts, and other line-oriented changes. I’d have my school programs memorized so I could type commands without a list.

Video terminals (and PCs) became common in the mid 80’s. Screen editors were still slow on video terminals (connected to shared runtime systems), but awesome on PCs.

BASIC was developed before even CRT terminals were a thing. You had to enter your commands into a teletype and see the output typed out. On paper. No frame buffer or character cell buffer, no ability to change the output once it was written. That informed the design of BASIC programming with line numbers. It was actually quite a powerful IDE, given the constraints it was operating under, and allowed non "computer people" to write and run programs. Dartmouth football players, for example, wrote a football simulation in BASIC that was featured in David Ahl's BASIC Computer Games like a decade later.

Line numbers were kept because line-oriented programming was easier to implement than a full-screen text editor and because they looked familiar to BASIC users. But many Microsoft BASICs, including GW-BASIC on PCs and Commodore BASIC, supported a sort of fake full screen: you could cursor around the entire screen and anything you pressed Enter or Return was scanned as a line and entered into BASIC. Smarts were built in to handle wrapped lines. This let you change a line in situ, hit Enter, and see the changed line entered into your program. Previous commands could be executed immediately provided they hadn't scrolled off the screen.

BASIC had to work on tiny chips and not fill the entire ROM and RAM by itself. Probably that’s the reason. Later basics (Quick, Turbo) worked as “IDEs”.

As a side note, neither early DOS nor CP/M had a full screen editor either, afair iirc. Edlin (poor man’s ed) is my earliest memory, which was a line-oriented editor. https://en.wikipedia.org/wiki/Edlin

I think this stackoverflow answer gives a good answer:

https://softwareengineering.stackexchange.com/questions/3097...

Here's a video approximating coding on a early-'80s home computer, complete with some simulated(?) NTSC TV ambiance effects:

https://www.youtube.com/watch?v=mOqguR3bBsk&t=1m8s

(Some things I didn't notice them getting into were `RESEQUENCE`, retyping a line with its number to edit a line, storing the program to flaky audiocassette, and losing the only copy of the game you were developing because you left your tape in, and your little brother absent-mindedly pressed the Record button while waiting his turn to play Parsec.)

Commodore BASIC and Atari BASIC both had on screen editors where you could LIST your program on the screen and cursor up and down and change the code and when you pressed ENTER on a line, that line was re-entered into the program. Most other BASICs either required you to retype the entire line or had a line editor (eg. Applesoft BASIC).

Atari BASIC could export a BASIC program as a text file using the LIST command. Once exported, an editor could be used to edit the code:

  LIST "D1:CODE.TXT"

Or you could only output part of the program, say from line 1000 to 2000:

  LIST "D1:PARTIAL.TXT",1000,2000

Then you could use the ENTER command to bring that code back in. If a program was already there, the lines would simply be inserted. If the ENTERed code had a line number the same as the program in memory, it would replace the one already in memory. This was a great way to have a subroutine library, kind of like #include in C:

  ENTER "D1:PARTIAL.TXT"

Outside of the examples above, it was difficult to have a full screen editor for BASIC because every line had to have a line number and you had to keep them organized. Also, the earliest microcomputers didn't have enough RAM for a full screen editor. The BBC Micro had a text editor in ROM but it couldn't be used for BASIC code. It could be used for other languages that were typically compiled.

Most other languages either had a full screen editor or you could use any text editor. For example, Atari Logo has a full screen editor where you can edit one PROCEDURE at a time with:

  EDIT "MYPROCEDURE

The first BASIC I used (1976?) was designed to run in a machine with 4K of memory (a 16-bit minicomputer). There was no operating system, nor no disk. You installed the program using a paper tape reader.

At this time, the best "full screen" editor we could find was actually a very expensive CRT terminal that did all of the editing in the terminal's memory. It required an operating system and a disk. The program read 1K of data into terminal memory, and using keys built into the terminal, you could move the cursor around and cut and paste. When done, it write the memory into a file, and read the next 1K of data.

The computer it was attached to had an editor like TECO (DEC), NSPEED (Data General), or EX (AT&T Unix). These were editors designed to be used on dumb terminals or even hard copy terminals (Like a TeleType ASR33, Silent 700, or DECWriter).

A full screen editor would need an operating system with support for files (Floppy or the outrageously expensive hard disk), and enough memory to support a program on top of the operating system, on top of the program you are editing.

MS-BASIC (for the altair) dates to 1975. At that time, ed was the standard unix text editor (vi, the VIsual editor, didn't exist until 1978.). Most early 80s computers used a variation of MS-BASIC from 1977, designed for 1977 hobbyist hardware, slightly modified, never updated, and burned into ROM.

Anyhow, Apple Pascal was available with a full-screen editor in 1979 (this required 64-K of RAM, a disk drive, and lots of disk switching). 1984-era MacBASIC had a GUI text editor (The mac shipped with 128K of RAM, 64K of ROM, and a 400K 3.5" floppy drive.

https://archive.org/details/mac_MacBASIC.335

In 1979 I was developing the same application on several different systems with Basic. Durango (https://en.wikipedia.org/wiki/Durango_F-85) and Sord (https://en.wikipedia.org/wiki/Sord_Computer_Corporation) are 2 of the names I remember.

Most had classic line numbers but one had a forward on full screen editor. You could fullscreen edit what was on the screen. This include adding new lines anywhere visible. Any action that made text scroll off the top was inaccessible and would be written to disk.

To get back to earlier lines you had save all and restart.

It was a combination of things. It allowed a simple line entry system to organize a collection of lines as a linked list, yielding a really simple program editor AND at the same time provided convenient (for the interpreter) labels to use as targets for the likes of GOTO and GOSUB

On Apple II computers you did have a screen editor of sorts. You listed the line you wanted to edit, you pressed ESC and you could move your cursor up to the line you wanted to change and overwrite it.

The last time I programmed BASIC was in the 1970s, and it was already over a decade old.

All the answers from the '80s make me laugh.

(Well, at least the laughing is true. )

The answer is RAM. Full screen editor required a lot of RAM for the machines of that time, leaving far less for the intended application.

I don't remember any fancy full-screen editors. I remember a CLI where editing meant I could enter a line of code or LIST what was already typed in (ordered by line number).

I remember writing programs first on paper, then transcribing them in. Line numbers were useful for that - making sure I didn't miss anything.

They were also incredibly useful when typing in programs from magazines!

for a lot of 80s computers the command line / basic environment was an interactive thing. It would immediately execute your commands. Some of those commands were for listing contents on disks and loading programs from disk/tapes. The simplest way to add the ability to build up a basic program on a command line is by a simple line editor where you get the classic '10 PRINT "Hello World"' which would immediately store away that line of code. Towards the end of my 8 bit days there were screen editors for things like doing 6502 assembly, and there was this cool language called "Action!" https://en.wikipedia.org/wiki/Action!_(programming_language) which also had a screen editor.

I first programmed in BASIC on an ASR-33 terminal. Try using a full screen editor on that device!

BASIC was a 1965 language. The interactive language that preceded it and was a shade better, was Joss, which ran on the Johnniac. Joss used line numbers.

basic was not developed in the early 80s - early 60s