Why did 8-bit computers choose BASIC dialects as "de facto" command-line interface, instead of contemporary Shell/Lisp dialects?

Question

While all three clans of languages predated 8-bit computers, they shares features like 1) imperative programming, 2) English-like keywords, 3) Prompt-Command-Parameters pattern interface. Why was BASIC chosen rather than the other two families, or a Console Command Processor extended from CP/M?

Thompson shell was released in 1971; LOGO (an educational dialect of Lisp) first appeared in 1967, and Lisp in 1958.

LOGO is quite a parentheses-free Lisp. As a comparison we have:

BASIC

10 FOR I = 1 TO 10
11 GOSUB 20
12 NEXT I
13 END
20 REM SUB WELCOME
21 PRINT "HELLO RETRO COMPUTING"
22 RETURN

LOGO

REPEAT 10 [ WELCOME ]

TO WELCOME 
  PRINT [HELLO RETRO COMPUTING]
END

Bourne shell(1979)

welcome() { 
  echo "HELLO RETRO COMPUTING"
}

for i in 1 2 3 4 5 6 7 8 9 10
do welcome
done

Answer 1

If we're not talking about BASIC as a programming language, but the operational commands that surround it, then the answer is that they surely reimplemented the command structure of existing timesharing systems that offered BASIC, in particular the 1964 Dartmouth Time Sharing System (the progenitor of BASIC).

There are nits to pick, however. The "command language" (OLD, NEW, RUN, LIST, etc) is not actually BASIC; it's a separate thing in DTSS. But many other systems that implemented a BASIC subsystem chose to implement the same command language, for familiarity.

One feature, presumably attractive to beginner users (the 'B' in 'BASIC') is the seamlessness between BASIC and the mechanisms of editing a program. For example, there is no overt "edit" program. Instead, command lines starting with a line number edit the current program source.

Another point that seems relevant is that some number of users of "home computers" would have seen timesharing BASICs, and familiarity is a good thing. Indeed, people tend to expect certain commands (OLD, NEW, etc.) to be part of BASIC, even if commands and languages are actually different.

And lastly, BASICs were often expected to reside in ROM. Adding complex command languages would have expanded the size needed.

Or to summarize it all: if you're reimplementing something that looks like an existing system (i,e,, timesharing BASIC), why stop halfway?

Answer 2

People nowadays think of BASIC as something lesser and generally tied to puny microcomputers, but BASIC was the language of choice for many scientific, engineering and business computers in the 1970s. It had a strong foothold with mini computers, years before the microprocessors made its debut on the desktop. Think

• HP (Instrument) BASIC for all their calculators, all the way to
• HP- Timeshare BASIC for their multi-user systems
• BASIC Plus for timeshared DEC PDP-11 systems (RSTS/E)
• WANG BASIC for their whole range of business machines
• IBM 5100 BASIC
• Olivetti 6060 BASIC
• Nixdorf BASIC

This list can be extended to basically all systems of the 1970s - all the way to IBM mainframes - and all of them predate 8-bit systems with their use of BASIC as main/single front end. In fact, BASIC was originally developed as front end for a multi-user system.

This was the environment 8-bit computers were placed in (or were they tried to fit in/grow up into). Here everything smaller than a mainframe, and intention to be user programmable, came either by default with BASIC, or could be ordered with it. BASIC was the language of choice for low-end and mid-range systems in the 1970s. To compete, BASIC was a must. Notable as well, next to all developers of 8-bit systems microcomputers were at some point exposed to them, seeing them as great tools to be used.

---

Equally important, 8-bit micros did start out extremely small. BASIC could get implemented with as little as 4 KiB of ROM and 4 KiB of RAM. All other solutions would need way more RAM/ROM to run and often random-access mass storage ((floppy) disk) as well. And while professional 8-bit systems soon grew to have 64 KiB and mass storage, this repeated with home computers again. The market was quite cost sensitive and RAM size was the easiest way to cut the price.

---

Last but not least, BASIC was interactive build about an embedded command line mode, so adding a few commands for system management (if at all) was a lesser task than writing a whole set of interacting operation system layers, shells and applications.

---

This command line execution is also what makes BASIC in all practical sense functional indistinguishable from any (other) shell language. Each and every command could be executed from the BASIC command line without being first turned into a program. Heck, this is exactly the way Apple DOS batch files worked. Each line read from the file was executed direct by the interpreter.

The differences between some Unix shell or BASIC as command interface is just syntax and names - nothing more than icing on the cake.

---

We're living today on an extremely high stack of layered development that simply hasn't existed back then - not even dreamt about.

---

P.S.: As command line the BASIC example wouldn't be 7 lines but rather a single like this:

FOR I = 1 TO 10 : PRINT "HELLO RETRO COMPUTING" : NEXT I

Answer 3

This was more of a marketing question than a technical one. The historical fact is that most vendors of 8-bit personal computers chose to include BASIC. The simple answer as to why they made this choice is pretty obvious - It was the standard.

So, slightly restating the question posed, one could ask "Why was BASIC the standard?" It was a standard in the sense that all the successful early entries to the marketplace included it. So, if a vendor wanted to compete in this market, they needed to offer feature parity with the competition first, then try to build from there. And the inclusion of BASIC was widely regarded by consumers as part of the feature set from the earliest personal computer products (Note 1).

• Altair 8800 (1974): Microsoft BASIC available as an add-on.
• Apple ][ (1977): Built-in BASIC, followed quickly by an enhanced version also from Microsoft.
• Commodore Pet (1977): Built-in Microsoft BASIC
• Tandy TRS-80 (1977): Built-in Microsoft BASIC

It's pretty easy to see a trend. Not only was inclusion of a BASIC dialect rapidly becoming standardized, but a familiar vendor was already dominating the market for licensed 3rd party BASICs. Indeed, Microsoft "cut its teeth" by dominating the market for BASIC more than a decade before the emergence of the "Wintel" standard. And MS-DOS was no slouch in terms of being a de facto standard OS in the interim, as well.

The question also hints at a skepticism about the merits of BASIC as a primary interface, vis-a-vis the other contemporary options. But not all technical merits matter in the end (BASIC had its pluses and its minuses), and markets are generally the deciding mechanism for what scales.

Note 1: The question appears to be about 8-bit personal computers, not earlier mini-computers or other devices that may have contained a microprocessor and which support a BASIC dialect.

Answer 4

BASIC was cheap on resources. Cheap on ROM, cheap on RAM, functional and productive. Nothing else came close -- not even Forth (which really required a disk drive to be truly usable, though there were exceptions).

In the microcomputer BASICs, program code and the source code were the same. The original text is consumed and parsed in to the internal token format, then reified back in to readable text when LISTed. Most every other system had to deal with the source code separately from the runtime code. BASIC only had to maintain its internal representation.

The line number scheme is the simplest of editors. No search, no cut and paste, no buffer management, compressed program source. If you can do a memory block move, you could edit a BASIC program. Type in the line number to create a new line, or replace an old one, tweak some pointers, and that's it. BASIC programs weren't so much as "compiled" as they were just continuously patched as the lines were entered in arbitrary order and the runtime image updated in place.

Even the "screen editors" on the PET and Ataris essentially came almost for free, as they did not change the actual BASIC editors per se, they simply changed the keyboard device and how it read lines to feed in to the interpreter leveraging the text stored in the screen buffer that was being displayed.

Later BASICs offered ways to change lines without rewriting them wholesale, renumber lines, but they weren't necessary. Nice to have, but not necessary. Just an added feature if you have the ROM space for it. (I'd rather have a RENUM command than a line editor myself.)

But the 8K ROM BASIC were simply wonders of capability (the 4K BASICs even more so). And, once committed to, it was trivial to leverage all of the inherent BASIC processing capability to add new commands for things like the disk drive, graphics, etc.

For all the horrors BASIC is renowned for, all told it was fabulously productive and efficient in practice for the time.

Answer 5

I started programming in 1981 at university & my first job (in 1982) was on an 8-bit Business Computer (The Durango).

BASIC was one of the big three languages - FORTRAN and COBOL were compiled and on bigger computers.

The expectation was that business programming was somewhat English-like. Forth had a significant presence in technical and laboratory instrument control but its stack handling requires a level of abstract thinking well above BASIC.

Non-programmers can follow the logic of a BASIC program. They can't really do that with an idiomatic Lisp program. Whilst Lisp has had a major role as a control language inside AutoCAD, again that's a selective market.

Update Regarding Will Hartung's comment about Forth requiring a disk drive, that's utter nonsense.

I had a modem with inbuilt Forth which could be accessed by a special AT command, so it then became a true command-line Forth computer accessed via serial terminal. Definitely no storage involved!

BASIC interpreters were also preferred on the Nixdorf minicomputer at my second job, which I started in 1983. Entire share registries, accounting, purchasing departments ran on this via terminals. This was a major mining company, I also knew of department stores running similar setups.

Programming was in chained 16KB programs with 1 character variable names (with optional digit) & comments took valuable coding space as they were in the same text.

Data access was to text file, random-access fixed-length binary and indexed ISAM files. All screen I/O and data access were via calls that used a lot of numeric parameters. Whilst the main logic was semi-readable, using the operating system's libraries was fairly impenetrable & you worked with an open binder of call numbers at your elbow.

A lot of people experienced BASIC on early 8 bit micros for domestic use but there was an entire world of relatively sophisticated business programming. Even in 1981, a Durango had a hard disk and ran up to three remote diskless workstations running the same software in that 8 bit OS.

Answer 6

I see 3 main reasons:

• The 8-bit computers were targetting amateur computer enthusiasts, and a lot of beginner children. BASIC were specific to each machine to allow easy access to keyboard, sound and graphics, with simple syntax, global variables, not too many concepts like functions, scopes, etc. to avoid losing the users. Imagine having to count the parentheses with a Lisp system. That probably wouldn't have been so popular
• The way most BASIC language store their tokens allow to minimize memory footprint. Each keyword can take just 1 byte. Even PRINT or WHILE take 1 byte in most BASICs. It means that you can write big programs without hitting the 16 or 48k memory barrier.
• The BASIC line numbers make it easy to report an error in a program. 8-bit machines didn't have any editor to go to line 1245... It also allowed dirty GOTO spaghetti code instead of clean procedures, perfect for hours of debugging fun :)

Not saying both points above couldn't be resolved with Lisp (which has interpreted versions beside compiled ones), but this language is meant for bigger and more powerful machines, and probably has a bigger ROM/RAM/stack footprint. So it would have needed a major rewrite anyway. While BASIC syntax is closer to other languages like C, Fortran and Pascal. The language had to be rewritten in assembly for each ROM and each machine anyway, so why imposing the peculiar Lisp syntax to beginners ?

Answer 7

Unlike many languages which require the use of a text editor separate from the language implementation, a BASIC interpreter includes a text editor built in. Further, someone with e.g. a VIC-20, a television set, and the manual would have everything needed to make the computer do something (e.g. play the Tank-versus-UFO game printed in the manual). Obviously having a tape drive and a blank tape would make the system much more useful, but those merely augmented the existing functionality of the system.

I can't think of much else that could have been included in ROM that could have allowed one to do anywhere near as much with a "bare" system as one could do with a computer that had a built-in BASIC interpreter.

Based upon my limited understanding of FORTH or LISP, an important advantage that BASIC has over it is that unless one deliberately seeks to do so, one would be unlikely to produce a BASIC program which could not be recreated by recording the output of the LIST command and then typing in the program in question. Languages which treat programs as data that can be manipulated can do some very powerful things, sometimes in rather limited memory, but an interpreter may have no clue how a program was created in memory or what would need to be done to recreate it.

To illusrate the point using a REPL-based language I actually do know, in a Javascript console, if one does something like:

var a=[[1],[1]];
a[2] = a[0];
a[3] = a[0];
a[4] = a[1];

An attempt to serialize a would list its contents as [[1],[1],[1],[1],[1]], but if one were to say, e.g. a[0][0] = 2; on the original array, the apparent contents of the array would be [[2],[1],[2],[2],[1]], while doing it on a reconstituted version of the serialized array would yield [[2],[1],[1],[1],[1]].

In order for a REPL-based language to be suitable for use in a late 1970s personal computer, there would need to be a standard means of converting a program in memory to a serialized from. BASIC has such a means, but other REPL-based languages don't.

Answer 8

Unix-style shells are optimized for environments with a lot of files in a relatively stable and fast to access, but complex structure - essentially, shells are programming languages that use files and directories as their main data type.

You found simple shell style environments on early office computers running CP/M and similar systems (still much more expensive systems than small home computers), more sophisticated ones on large Unix-driven machines.

Storage devices that kept enough files on line at a time for shell style languages to be optimal were out of economic reach for the typical early 8 bit hobbyist system user.

Answer 9

Isn't this discussed in the book, Decoding Liberation: The Promise of Free and Open Source Software By Samir Chopra, Scott D. Dexter? (See page 13). Basically, copyright issues and monetization strategy for LISP ended up spawning the open source movement. BASIC was more readily available with license, or easily pirated.

Answer 10

The Question "Why did 8 Bit computers choose basic" should be changed to "why did 8Bit computers choose MICRO SOFT basic." Because from the beginning of the 8Bit-era to the emergence of 64Bit plattforms Microsoft did dominate the basic market with 90% to 98% of installments.

Even more important, Microsoft was the first affordable supplier of ANY 8Bit-programming environment which ran on affordable hardware and was easy to pirate - which has always been the best method to set standards. In my humble oppinion 99% of all computer beginners from 1970 to 1980 did start with MICROSOFT Basic, be it the Commodore version, the GWBASIC variation and so on. Even between 1980 and 2000 Microsoft easily had a market share of 90%.

Lets look back to the beginning of MICRO SOFT BASIC in 1975: It ran on cheaply available 8080/Z80 systems. Back then these systems were brand new and totally bare of any software at all. NULL NADA NOTHING. One did write programs by punching raw machine code values into the memory chells, sometimes by simply connecting raw wires. No keyboard, no screen, no C, not even an assembly code compiler. Your typical standard Altair had 256 Bytes of memory and NO ROM/OS at all. You hacked the memory cells directly and prayed for the best, using the reset button a lot.

Then came MICROSOFT BASIC which only required 4kByte of ROM and 1kByte of RAM and was in all aspects a lot better than everything on 8Bit before with no competition at all. Even in 1975 an upgrade to 1 to 4kByte of memory and a 4/8kByte ROM wasn't too expensive and so everybody who actually wanted to something useful did use basic at least part time. Not to mention that you basically get a basic (pun intended) Disk Operating System ontop - just remember, your 8080 system didn't even have any code to access storage at all, LOAD and SAVE were just epic features back then.

I guess it was not intended to make basic the standard but the early bird catches the worm. And to be honest, until I went into the 32Bit world I was quite happy with basic. There never were any real alternatives besides assembly language anyway.