While all three clans of languages predated 8-bit computers, they shares features like 1) imperative programming, 2) English-alike 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:


10 FOR I = 1 TO 10
11 GOSUB 20
13 END




Bourne shell(1979)

welcome() { 

for i in 1 2 3 4 5 6 7 8 9 10
do welcome
  • 7
    Why, in the 8-bit era, was there a perceived need to design and build machines specifically designed for running Lisp? (Yes, in theory one could run Lisp on an 8-bit machine if I’m recalling the availability of Lisp environments correctly, but those were painful to use). – Jon Custer Apr 12 at 16:10
  • 14
    The Jupiter ACE switched it up a little by embracing Forth rather than BASIC, which is a lot like backwards LISP. It was underpowered though, besides anything else — black and white and with only 1kb RAM for £90 in 1982, when the colour 16kb Spectrum was £125 and would be £100 within a year. – Tommy Apr 12 at 16:13
  • 5
    I didn't use Lisp back then, but from what I've heard, Lisp implementations in that era tended to freeze up unpredictably for long periods of time in order to do garbage collection. Both the hardware and the garbage collection algorithms have improved a lot since then. This might have been a showstopper on these old, slow machines. – Ben Crowell Apr 13 at 1:02
  • 12
    Why do modern computers ship with Windows? – Thorbjørn Ravn Andersen Apr 13 at 10:06
  • 14
    Possible duplicate of "Why didn't the Wright Brothers just start with the 747?" – Harper - Reinstate Monica Apr 13 at 15:52

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?

| improve this answer | |
  • 3
    To add to Dave's comment, recall that the original BASIC was a compiler. The "base environment" was a command line that just happened to understand line numbers and invisibly copy that content into a file if there was a number. That shell had the few commands he mentioned. BASIC itself was a compiler that ran when you typed RUN, like typing cc into zsh. LIST was cat, NEW was rm, etc. – Maury Markowitz Apr 14 at 18:00
  • Indeed - it is worth noting that computers that were provided without BASIC in ROM generally did very poorly in the market. A lot of homecomputers in the 70s and early 80s were bought with learning programming as a specific goal (teaching your kids to program was seen by many parents as an important goal) and BASIC was the most popular educational language of the era. Computers that lacked a builtin BASIC were largely seen as only useful for playing games. – occipita Apr 24 at 7:51

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

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/grow up into. Here everything small, with an 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 ever 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 example would go like this:

| improve this answer | |
  • 2
    Texas Instruments calculators also use basic. Modern ones leave you the choice between basic and python, but basic remains. – Jean-François Fabre Apr 12 at 19:35
  • 2
    How about 4K ROM and 128 bytes of RAM (of which 64 were made available to the user)? – supercat Apr 12 at 22:24
  • 4
    An additional aspect that favoured BASIC was that the pioneering 8-bit machines were developed by computer/electronics engineers and technologists. They were concerned with getting a job done, not with theory, and that's what a BASIC interpreter with an immediate command processor can bring you. Academic projects like Lisp and Logo were ivory-tower. Unix and its shells were always too big for the 8-bits – scruss Apr 12 at 22:36
  • 2
    BASIC in the punch card era had an advantage over languages like COBOL: since each card was numbered, you didn't have to keep them in order. I think BASIC was the de facto language because it was what was used to teach programming, and why move on if it was good enough for your needs? – Howard Miller Apr 13 at 14:56

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.

| improve this answer | |
  • 1
    Fair enough, then again, for the question why, weren't it the minis before that influenced the decision to implement BASIC? For Woz it was sure his exposure to HP BASIC that made him write Integer BASIC. Similar the Commodore PET development. – Raffzahn Apr 12 at 16:56
  • 1
    I do think your answer is a good one. No disagreement here. I just understand the question as asking why BASIC has been chosen as primary UI for 8 bit. Something that of course must originate before the masses of commodore, Tandy and alike have been sold. – Raffzahn Apr 12 at 20:05
  • 1
    @Raffzahn Sure. I think the OP is likely skeptical about the merits of BASIC vis-a-vis contemporary options. I'm simply pointing out that not all technical merits matter in the end (BASIC had its pluses and its minuses) and markets are the deciding mechanism for what scales. – Brian H Apr 12 at 21:02
  • 3
    One also has to remember that BASIC was seen as a FORTRAN light, i.e. it had what made FORTRAN great. Quite comfortable mathematical formulas handling (better than the shell proposed above or lisp). The market of micros would not have risen if maths/physic problem sollving capability hadn't been a big, big selling points. Gaming only began to be an appeal after the pioneer machines had been established, so in the 80s. – Patrick Schlüter Apr 13 at 13:30
  • 3
    The first time I saw a computer, it was a ZX81 in 1981. It was in a group with my Karate buddies and teachers, and the whole evening was discussing, experimenting MATHEMATICAL problems. Basic was ideal for that, really. – Patrick Schlüter Apr 13 at 13:32

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 ?

| improve this answer | |

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.

| improve this answer | |
  • 3
    I agree with what you say about BASIC, but disagree about FORTH. The latter produces very compact code, and runs faster than BASIC. Its disadvantage is its difficulty to write correct programs, especially for beginners. – DrSheldon Apr 14 at 19:08
  • It's requirement for a disk drive makes it a non-starter. BASIC is much more self contained than Forth is. The Jupiter Ace is a stand out, with its cassette based Forth. But if anyone thinks a BASIC listing is bad, they haven't looked at decompiled Forth. I don't know how a binary only Forth can reclaim memory from redefinitions. Conventional Forth can't (which is why you tend to throw away the entirety of your program and reload it from source in Forth). Some BASICs suffered less so from this, such as leaving behind space for variable no longer used. – Will Hartung Apr 14 at 20:02
  • 2
    I used Forth on a PET, and saved things on cassette. I don't know where you got the misconception that disk drives are needed. – DrSheldon Apr 14 at 21:05

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.

| improve this answer | |
  • 3
    Please read the question. A lisp REPL loop could have done the same. – Joshua Apr 13 at 1:48
  • 1
    I hadn't noticed you mentioning Logo earlier. A command shell would only be useful with a medium from which to load programs. Also, the process of going from a BASIC program to a listing seems, or from a listing to a program, seems cleaner and easier than trying to do likewise with Logo or LISP, though I've never worked with those languages to any meaningful degree. – supercat Apr 13 at 14:17
  • @Joshua - in 3 KB RAM on a 6502? Not usefully, no. – scruss Apr 18 at 21:00
  • @scruss: Now not enough ROM would be a good answer to this question. – Joshua Apr 19 at 2:45
  • @Joshua: I extended the answer to say why BASIC is more suitable for late 1970s microcomputers than other REPL-based langauges. – supercat Apr 19 at 17:02

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.

| improve this answer | |

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.

| improve this answer | |
  • 2
    Not really, as for one, no manufacturer needed to 'pirate' BASIC, as the language wasn't copyrighted, but more important, all of this happened at a time before all of the legal protection scheme came into existence/was applied to software. All the way until the 80s software was considered open by default. Yes, hard to belive from today's PoV. – Raffzahn Apr 14 at 8:55
  • @Raffzahn I would like a cite for noi legal protection that I suspect IBM did not agree to that. ATT&T did not. DEC did not - see BLISS and why C was written – mmmmmm Oct 18 at 16:34
  • @mmmmmm BASIC as a language was never copyrighted - and especially not by any of the companies you mentioned - or can you cite any source about them paying licence fees to implement their versions? – Raffzahn Oct 18 at 17:18
  • My comment was re " but more important, all of this happened at a time before all of the legal protection scheme came into existence/was applied to software. All the way until the 80s software was considered open by default. " – mmmmmm Oct 18 at 17:22

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.