Ask HN: Why did BASIC use line numbers instead of a full screen editor? | Hacker News Reader

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

31 pointsamichail74 comments

Home computers in the early 80s were certainly capable of providing responsive full screen editing, so why did they use line numbers for BASIC?

View on HN

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).

Microsoft didn’t “port” their software in the traditional sense. It was a clean rewrite for each platform.

For instance, the Apple // graphics memory layout was really weird.

It was not a clean rewrite for each platform. It wasn't even a clean rewrite for each processor. Forensic analysis proves this. For example, the MICROSOFT! Easter egg from the 6502 version of Microsoft BASIC remained in the 6809 version even though there is no longer code to display it.

Source: https://www.pagetable.com/?p=43

> Microsoft didn’t “port” their software in the traditional sense. It was a clean rewrite for each platform.

Not true. See https://devblogs.microsoft.com/commandline/microsoft-open-so... in particular:

> This source was ‘translated’?

> Each of the assembly source files contains a header stating This translation created 10-Feb-83 by Version 4.3

> Since the Instruction Set Architecture (ISA) of the early processors used in home and personal computers weren’t spectacularly different from one another, Microsoft was able to generate a substantial amount of the code for a port from the sources of a master implementation. (Alas, sorry, we’re unable to open-source the ISA translator.)

You also write:

> For instance, the Apple // graphics memory layout was really weird.

That’s largely irrelevant because the core of Microsoft BASIC was text-only and had no graphics support. Graphics support was an extension, which was highly platform-specific, since platforms varied greatly in terms of their graphical capabilities and how those capabilities were implemented

Full screen editing also requires much more RAM. Late 70s and early 80s computers might have had 4 KB - 32 KB RAM. With such limited system, it is hard to host a full screen editor or any advanced compiler with jump labels.

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.

Having used both, and having developed on both I agree. Also Hazeltines, and Heathkits HAD cursors, but the computers they were hooked to, did not have the ram to support it, in basic. VI was just around the corner, but for UNIX.

> 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...

<GrumpyOldManVoice>

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...

</GrumpyOldManVoice>

You can still have a "fullscreen editor" environment on a 320 wide display, case in point: the KC85. You could move the cursor around on screen and if there was a command under the cursor, it would be executed:

https://floooh.github.io/tiny8bit/kc854.html

Many applications used the same menu system and thus automatically inherited this screen editor functionality.

Apart from that, Forth also had a screen editor, you could define a new word, run it, and then move the cursor up over the original definition and modify it without having to retype everything:

https://floooh.github.io/tiny8bit/kc854.html?mod=m026&mod_im...

...the builtin KC BASIC on the other didn't have such luxury, most likely because it also needed to run on other home computer systems that didn't have this screen editor capability.

> in those days, most of us used 300-baud VT100 terminals, which were VGA (640 X 480).

VT100 terminals didn't have addressable pixels at all, nor colors - only two brightness levels. The screen was an 80x24 character matrix. You could move the notional cursor around by sending escape sequences and thereby place characters where you want within that matrix, so full-screen editor support was possible (and sometimes done), but there was nothing VGA about it.

There were also some box-drawing characters in the DEC Special Graphics character set, so you could draw rectangular shapes using primitives like ┣ and ┻. Effectively I guess that sort of got you a 161x49 matrix for wispy images.

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.

labels are strictly better. idk if you've ever had to renumber your basic or fortran code

I did a lot, by hand. I was on the Apple ][ in my BASIC days, they also had a utility to help you renumber your code. (Both versions of BASIC for the Apple ][, Integer BASIC and Microsoft's Applesoft BASIC, didn't allow for inline labels)

https://archive.org/details/applesoft-toolkit/mode/2up

If you're really old you'll remember this one too:

https://yesterbits.com/wp-content/uploads/2013/06/600-2024-0...

I prefer to name my labels L00001, L00002, and so on. One for each logical line of code.

(Why yes, I am suggesting that there’s no difference between the two, and so “strictly better” is …)

you choose to do that rather than more descriptive targets like 'loop' and 'exit'?

I prefer that people get the joke (and to use languages where this isn’t a problem).

GWBasic had a renum command that would renumber all your lines to use the same consistent interval spacing.

I did a lot, and when the renumber range was added... we leapt for joy.

If anyone misses GOTO, GOSUB, RETURN control flow, there's a modern language that has it in the form of features called diverts and tunnels:

https://github.com/inkle/ink/blob/master/Documentation/Writi...

It's dedicated for writing narrative games.

In Atari BASIC, you can set a variable to a number and GOTO or GOSUB VARIABLENAME.

  10 MYSUB=50
  20 GOSUB MYSUB
  30 PRINT"END"
  40 END
  50 PRINT"MYSUB"
  60 RETURN
  RUN
  MYSUB
  END
  READY
  _

You are an evil programmer. If you printed on line 50 50 PRINT MYSUB-40, "MYSUB=", MYSUB. You would not know if you were printing your own program, and what 'MYSUB' actually was: A literal string or a memory value or a memory reference. It is for this very reason that 1) Clarity needs to be foremost in designing and implementing programs, and 2) Structured programming was invented and 3) Most Microsoft products fall short in both categories, and also Atair "Computers."

If you think that's bad, check out the Atari BASIC code in issues of the ANTIC and ANALOG magazines. There is some real evil wizardry in some of those programs.

Another oddity about Atari BASIC is that you can put any binary data in a string, such as machine code, and then execute the code in the string using:

  50 RESULT = USR(ADR(MLSTRING$))

As for points 1 and 2, I learned those things over 30 years ago. I don't get your, 'Atair "Computers"', reference. If you meant, 'Atari Computers', or 'Altair Computers', I still don't get the reference.

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

Microsoft even included REMLINE.BAS

https://github.com/tangentstorm/tangentlabs/blob/master/qbas...

  Microsoft RemLine - Line Number Removal Utility
  Copyright (C) Microsoft Corporation 1985-1990
  
  REMLINE.BAS is a program to remove line numbers from Microsoft Basic
  Programs. It removes only those line numbers that are not the object
  of one of the following statements: GOSUB, RETURN, GOTO, THEN, ELSE,
  RESUME, RESTORE, or RUN.

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.

First lessons in extensibility were in BASIC, when the very young future software designer strategized line number increments.

Anyone whoever programmed on punch cards always numbered them so the you could sort them if you ever dropped your deck. Strategic numbering was even more important then. Most of us preprogrammed the punch machines, via a punch card itself mounted to a drum, to help with the numbering.

Don't forget to draw a diagonal line across the side of your card deck. Don't skimp and use a pencil, get a nice felt tip marker.

My dad said guys he worked with back in the 1960's would have stacks of library routines on punch cards that they would assemble their programs from with a minimal amount of purpose written code. Once it was finished they run the stack through a duplicator that would also renumber the cards. Then they'd take the original deck and stick the library functions back in their library.

I don't think that quite explains it though. It wasn't as if the idea of a screen editor hadn't occurred to them.

So if that was the reason it was because of compatibility.

There's probably also the issue of keeping the code text in memory, an issue when talking about the zx80 end of the /spectrum/

BASIC was from 1964, screen editors weren't a common thing at that point in history. Many of the implementations that made it into early home computers weren't too distantly altered from that original version.

I mean at the point when basic was being ported to home computers, thus the comment about backward compatibility.

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.

300 baud? Luxury on an acoustic coupler.

150 baud (as a channel for a terminal running at 110 baud) was far more typical.

You might be right that it was only 150 baud; honestly don’t remember.

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.

Dartmouth BASIC actually emerged in 1964, predating DEC (vt100) terminals, running on GE mainframes.

https://en.m.wikipedia.org/wiki/Dartmouth_BASIC

I understand that the first versions of Dartmouth BASIC used teleprinters.

https://en.m.wikipedia.org/wiki/Teletype_Model_33

DEC had paper terminals (LA34, LA36, LA38). VT52 was I believe the first video terminal. Then VT100, then VT220.

But it all started on the DECWriter paper terminal.

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.

CRT terminals were a thing by then. Spacewar!, for example, used a CRT in 1962, and the original PLATO paper from 1961 (https://ieeexplore.ieee.org/abstract/document/4322215) says:

> The computer communicates to each student by closed circuit television. It selects slides and writes or erases sentences and diagrams on a storage tube. These two outputs are superimposed and displayed on the student's television screen. Not only are textual materials presented to each student at a rate determined by that student, but the computer frequently poses questions.

(See also https://core.ac.uk/download/pdf/4812121.pdf p36 for more details.)

Also, it doesn't need to be a CRT. Plasma displays were developed for PLATO IV because, to quote the 1966 paper (https://dl.acm.org/doi/pdf/10.1145/1464291.1464349):

> Display technology, however, has not kept pace with these advances. The TV-storage tube displays, of course, perform well in the PLATO system, and other CRT devices are used successfully in information retrieval systems. However, no display device is now available that performs well, and is sufficiently inexpensive for use in these large systems.

This make it possible to read the 1967 Final Report of the BASIC (https://files.eric.ed.gov/fulltext/ED024602.pdf) in context. When they write:

> Our experience does not include what is usually called CAI. While more elaborate CAI systems using fancy terminals (including TV-type presentations) could be attached to a general purpose computer system such as ours, the terminal costs would be much greater than those for teletype machines.

the "CAI" there means "computer-aided instruction", and is, I think, mean to include PLATO with its more advanced displays.

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 didn’t realize that the “Edit” program didn’t come with DOS until 1991

Edit came with DOS, but it was a handler for QuickBasic. Hence the EDIT was the quickbasic ide with no basic.

Chips? When BASIC came out, chips were all in the chip box. Memory was magnetic donuts, and large scale integration wasn't until 1970.

As a user that started in late 1970, and used mini computers with core memory, I am going to have to confirm this. Chips came in a bag w/ fish.

ROM Basic 1.0 supported full screen editing, you just had to hit return on the edited line. (circa 1981 ). I think that BASICA did also, but I need to check.

I think this stackoverflow answer gives a good answer:

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

Take this detailed answer and view it with the perspective of having to fit BASIC along with everything else in ROM into 12KB (in the case of the Apple II).

The TRS-80 level 1 ROM was 4k and the BASIC had the luxury of exactly 3 error messages: What? How? and Sorry.

> 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

This doesn't make much sense to me.. why does storing the lines in a linked list require line numbers?

The editor (if you could call it that) was stateless. There was no ”current position”. Its only commands were

- list lines X to Y

- “change line X to ‘foo bar baz’”

- discard the entire program

They could have chosen to use indexes for line numbers, but allowing programmers to label each line with a ‘virtual’ line number made it somewhat easier for programmers to keep track of where code lived (imagine having to keep track of the fact that, after inserting three lines to the subroutine starting at line #100, the subroutine formerly starting at line #200 now starts at line #203)

It also meant that the interpreter didn’t have to make such adjustments to subroutine calls in the program (changing “gosub 200” to “gosub 203”)

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

"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."

My first employer (now known as GE Aviation) back in the 80s had mainframes from Honeywell that worked the same way. GE Aviation had started with GE computers, had sold off its mainframe GE business to Honeywell in the early 60s and GE Aviation continued to use derivative models for decades later.

After listing a bunch of code (Fortran, of course) onto the screen, you'd cursor around making your changes, then hit the F1 key, which was programmed to send the screen one line at a time. God forbid that you'd spend a serious amount of time making those changes, because the modem (yep, we used a modem WITHIN the company) would time out, you'd disconnect and lose all your work.

I forget how we edited non-code files, but I guess that they must have had line numbers too.

Fortunately, we had systems other than the Honeywells that we could use (just about everything you could name), but most of the older internally developed software resided on the Honeywells.

Were they actual Honeywell systems? Honeywell bought out the computer divisions of both CCC (Computer Control Corporation) and GE (General Electric). Of course, the original BASIC was written on a GE-225.

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. )

From an old guy who can remember pre PC ... Yeah! And all the assumptions of carefully considered invention/design for PC Basics ... ha ha ha ;)

The various BASICs were copies of what came before, and what came before had line numbers. As per the old joke ... "Why do ducks have feathers?" answer "Because their parents had feathers."

Look to the early interactive BASICs (wikipedia has a detailed article on Dartmouth BASIC) - line numbers were a convenient way to identify lines for editing and for control flow.

The last time I programmed in BASIC was only a few years ago, while I re-enteded a few classic games, and added lines so I could cheat. yes, way back then, the programs ( program logic ) cheated, but I got them back.

NOTE: How to disable AI? "Find my printer."

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!

I would have you know, that the ASR-33 terminals that had missing power switches, have left an indelible dent on my right index knuckle that I can feel to this very day. Chugga-Chugga-Chugga-

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.

https://dbpedia.org/page/JOSS

"It pioneered many features that would become common in languages from the 1960s into the 1980s, including use of line numbers as both editing instructions and targets for branches, statements predicated by boolean decisions, and a built-in source-code editor that can perform instructions in direct or immediate mode, what they termed a conversational user interface."

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

Reply on news.ycombinator.com