BASIC and the ROMs that changed the world (and then disappeared)

Once upon a time, Now was the future. For me, Now started on my eleventh birthday in 1983. That day I got an 8-bit 64 Kb Japanese computer called the Sharp MZ-700, an obscure home computer even when it was new. This meant that there were very few games, or other software, available for it. If you wanted to do something, you had to do it yourself.

This is where the programming language BASIC came in. Sharp included a variant, S-BASIC, on cassette. I knew that if I managed to learn it, I could program games myself.

So the first thing I did every time I turned on the computer, was to load BASIC from this cassette. Loading was without exception a time-consuming and excruciating experience, but the second it was loaded, a simple yet magical greeting promised a glimpse of the future.

«Ready,» it said. And Ready I was!

But the world had been greeted by BASIC years before this. The programming language was created by John G. Kemeny and Thomas E. Kurtz at Dartmouth College in 1964. They had a few design principles, one being that the code should look as much as English as possible. They also postulated that there should be only one statement per line. One could say that their philosophy was akin to the saying “as simple as possible, but not simpler”. Unlike the interpreted versions that later would dominate home computers, Kurtz and Kemeny’s BASIC compiled to binary format. As such, BASIC programs performed more or less on par with other languages.

At first, the creators didn’t imagine BASIC being used anywhere but on the Dartmouth College’s General Electric computer system, so they didn’t bother standardizing the language through an official standardization organization. But after they set BASIC free, it spread to other universities with systems such as PDP-11, Data General systems, Hewlett-Packard computers, etc.

But the more BASIC spread, minor discrepancies started to creep in. Dialects were the result. To some, this was a disaster. In 1975, the legendary pioneer computer scientist Edsger W. Dijkstra commented: “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration”.

He was both right and an unbearable snob at the same time. The combination of the advent of good time-sharing technologies for the mainframes of the era, and BASIC, was democratizing computing faster and further than anyone could quite predict. But even that was just a taste of what would come.

That’s because Dijkstra’s quip was, ironically, perfectly aligned with the biggest computing revolution ever. In the mid-1970s, home computers suddenly appeared on the market. Intel’s first processors found their way into products such as the Altair 8800. Other microprocessors from Zilog, Motorola and Mostek, soon followed, and found their way into products like Apple II, Commodore Pet, and others.

Regardless of the microprocessor at their core, all of these systems were under powered compared to the minicomputers that preceded them. But their relative affordability still made them immediate successes. The upside of limitations was that they forced vendors to find a programming language that was small enough to fit within their constraints. The language also had to be immediately understandable for amateurs that didn’t have any formal training. BASIC fit both criteria perfectly.

The language had lived its first 10 years comfortably on Big Iron computers and enabled non-expert academic users to use computers as tools. But it was home computers that made BASIC a tool for the masses: millions of new computer users from all walks of life.

In most of these computers, BASIC found its way into ROM. Whoever thought of putting BASIC on ROM chips, was a genius, even if that person probably didn’t understand the would-be historical implications of their choice.

Why do I think ROMs are so important?

My computer was a blank slate when it booted. I had to choose to use BASIC. But the first thing owners of home computers from Commodore, Amstrad, Sinclair and Apple was instantly greeted by when turning on their computer, was BASIC’s friendly “Ready”. From then on, BASIC was the computer’s programming language, operating system, UI, editor and shell in one. BASIC was, for all practical purposes, the computer’s personality.

Of course, many home computer owners probably never used BASIC as a programming language beyond the mandatory “hello world” variants. But everyone used rudimentary features of BASIC to load and start games, educational software, drawing programs, and more.

And even these users probably used BASIC without knowing it, because:

• BASIC was your calculator:
  PRINT 5/2
• BASIC could be your typewriter
  PRINT /P “Dear John.”
• BASIC got the time for you
  PRINT TI$
• BASIC let you compose music
  MUSIC “+A3+#F1+B3A+#F1A+D3A”

In 1983 BASIC was the only computer UI home computer owners had ever used. There was no Windows back then. BASIC was the window. For most users, it would stay that way for years to come; the Mac was an expensive niche product when it debuted in 1984, and Windows 3.x was seven years away. The upshot was that, should these users want to explore programming, they had BASIC literally at their fingertips.

You would think the fathers of BASIC were proud of the impact their little language had had. But Kurtz and Kemeny never liked the built-in BASICs much. They used the rather derogatory term “Street BASIC” to describe variants that deviated from their original. Deviations often consisted of additional commands tailor-made for vendor specific computer systems and hardware, i.e. things like graphics and control of peripherals. If the computer supported graphic sprites, BASIC probably contained custom-made commands to control them. If it had multichannel sound, you could utilize those too through custom BASIC commands. The short one-line BASIC examples, above, were from Sharps S-BASIC. As you can see that BASIC even had custom commands for using the plotter/printer.

This increased BASICs usability for owners of the various computer systems, but reduced compatibility between computer systems. This was the originators’ main gripe.

But in my opinion, this Cambrian Explosion of BASIC variants was something they should have felt extremely proud of. By 1987, 15% of American homes had a home computer, meaning that up to 36 million people were exposed to Street BASIC. If we extrapolate these number by estimating similar figures for Japan and Western Europe, the world-wide number may have been the double. This was indeed a revolutionary reach compared to the few thousands that previously had access to it on mainframes in universities and large corporations.

To criticts such as Dijkstra, and to a certain extent BASIC’s fathers, the home computer BASICs were lacking because they didn’t have any of the more advanced features of other languages.

The Street BASICs…

…had no compilers and linkers that produced optimized binary executables. Instead, BASIC was interpreted

…had no concept of modules and libraries. That meant that a Street BASIC program had to be self-contained

…did not support named functions. Instead, the program had line numbers that you could use the command GOTO to jump to (probably one of Dijkstra’s main complaints)

…did not support using a separate text editor for programming. In addition to every other role BASIC filled, it also was its own editor

…had no concept of scope or immutability, i.e. variables were always global, and their values could always be changed

In any other context, these things would be seen as major shortcomings. But to me, they are limitations with a purpose; if you let me paraphrase, in this case limitation is the mother of invention.

So the upside of the Street BASICs’ limited scope was that…

…the lack of a compiler made programs immediately testable and runnable. There was no extra step between you, the program and its resulting outcome

…the ommition of meaningful functions and sub routines meant that you had to think about your program as a recipe with step-by-step instructions. This is not only a format most people are comfortable with; this is how the algorithms of the human mind are. Just think about how a child would describe its day: “We went to kindergarten, and then this happened, and that happened, and someone said this, and someone did that”. That’s descriptive and linear, just like old-school BASIC

…no external editors meant, again, that there was a direct connection between the computer, its user and the software being built; the use of line numbers made using the crude line editor understandable and instinctively easy to use

…global variable scope really only was a consequence of not having functions; there simply were no need for protected or local variables, making variables easier to understand for new practitioners of BASIC

The most important difference between 80’s BASICs and other languages, however, was that the former lacked the concept of modules and libraries. But this, too, was an important limitation that actually lowered the barrier of entry; as mentioned above, the computer makers had to create top-level commands for, among other things, controlling hardware that were unique to the computer. This tight coupling between hardware and software again minimized the difference between BASIC and the computer it ran on. BASIC and the computer it ran on, seemed like one and the same.

Another good thing that came out of this shortcoming was, arguably, that it was easier to get an overview over your program: Anything it did, was visible in its source code; there never was a doubt as to where functionality were defined.

For all practical purposes, BASIC is seldom used and mostly forgotten today. But given my praise for it, why is it like that? As I see there were three reasons, and as time went by, their accumulated effect was devastating.

Reason #1.

The IBM PC, and later it’s clones, completely overtook the home computer market. On the PCs, very little were in ROMs. Instead, MS-DOS was usually loaded from diskettes or hard drive, and suddenly the operating system itself became the face of the computer. Not BASIC.

So from the get-go you were one degree removed from BASIC. If you wanted to use it, you had to explicitly start it after you had started DOS. BASIC was in that sense just like any other application. Within the BASIC application you typed and run your BASIC programs as you did on the previous generation of home computers. But, ironically in a world where DOS was the face of the computer, there was no immediate way to run saved BASIC programs from the MS-DOS command line. You had to load the BASIC environment first and run them from there.

All in all, BASIC on these machines felt like an afterthought.

Reason #2.

If Street BASIC had caused incompatibilities between computer systems earlier, the newer OS-based PCs could cause incompatibilities within a system.

Since BASIC for MS-DOS were run from disk, you could obtain and use any version of BASIC that you liked. Borland’s Turbo Basic might interest you more than the Microsoft offerings. You might call this freedom of choice, something most of us value. But the downside was that if you gave your program to a friend, you couldn’t be certain that your friend’s BASIC were the same as yours.

And even if you didn’t choose to use non-bundled BASICs, but exclusively used the version that came with MS-DOS, you could be in trouble anyway. Before MS-DOS 5.0, GW-BASIC was bundled with the operating system. It was more or less like the Dartmouth inspired ones you had found on home computers. But if you had MS-DOS 5.0 or newer installed, GW-BASIC had been replaced by QBasic.

QBasic was an attempt at a modern BASIC. Depending on your point of view, it really was an improvement. From a usage standpoint, it was quite different. You edited your BASIC programs in a dedicated editor, and when you ran them, the editor was completely replaced by a new screen. On this screen you could interact with your programs. When you were finished, the interactive screen closed and you were back in the editor. The tight coupling between programming and usage was now gone.

Language wise, QBasic got rid of line numbers (unless you insisted on using them). Instead, it gained labels and sub-routines with named parameters. You could also differ between local and global variables. To a certain extent, you could even explicitly type variables. It looked more like BASICs to come, than the old ones it replaced. But even though these represented a maturation of the language, it was also the start of turning BASIC from being a language where you described your algorithm step by step in a linear fashion, to a non-linear one.

All of this arguably made for a better BASIC. But the changes also made the language less comprehensible for beginners. BASIC stopped being basic.

As for compatibility, GW-BASIC programs would mostly run fine in QBasic, provided that the programs were saved as ASCII files. But as this was a non-default option, few programs were. The other way around was more or less impossible. Given the improvements in and modernization of QBasic, programs written for it could not run on GW-BASIC.

But even if you and your friend’s software stack was identical, issues could still arise. Given the modularity of PCs, you couldn’t even be sure that the graphics modes supported were identical between them. That was a solvable problem, but still a nuisance.

Reason #3.

Windows, and similar graphical user interfaces, removed BASIC even further from its roots by being something very different. You could of course choose to stay text based in a windowed world. But in that context, staying text based just wasn’t very satisfactory.

The main problem with adapting BASIC to work with windows, is that Windows programs is a collection of, well, windows and buttons, text fields, etc. Even though parts of the software can be somewhat step-by-step, most of the software consists of fragments catering to each button, text field and window independently. The code has no obvious entry point, and can’t be read and understood as a recipe from A-Z.

We now also got a world where the environment was so function rich that it was no longer possible to have a separate command for each function of the computer. Libraries and modules became necessary, and the notation changed into something like Module.Class.Sub(). The modularity made the ecosystem grow so big that almost no one could have a complete overview of it anymore.

This was inevitable, but the sheer size of these modern programming languages and their corresponding libraries, is now so large that the barrier of entry for newcomers is orders of magnitude bigger than it was in the 80s.

To be clear, it is with modern programming languages — anti-BASICs — I earn my living. I wouldn’t have it any other way. But BASIC was my entry point. After a few years I moved on to Pascal, Delphi (Object Pascal), Java, JavaScript, then Perl. In recent years I’ve mostly worked with Python and a few other languages depending of what kind of problem it is I’m trying to solve. Lately I’ve been dabbling with Go. Without BASIC, I probably wouldn’t have done any of this.

That’s why I don’t agree with Dijkstra’s somewhat condescending view that it’s impossible to teach good programming practices to those who learned BASIC first. Most of the programmers around my age that I know of, has had a similar way into professional programming.

If I lament anything at all today, it’s the fact that we no longer have an easy point of entry into the profession I love.

We lost something with the disappearance of the ROMs.

POSTSCRIPT

I thought I’d end this overly long article with a parting gift to you. What’s more fitting than the graphic above?

It was made using PC-BASIC, very much a non-ROM clone of GW-BASIC. It is, ironically, written in Python, a language that is often described as the BASIC for the modern era (which it — as a multi-paradigm language with modules, classes, procedures, functional programming, and beginning support of async execution — just isn’t).

Earlier in this article I wrote about incompatibility between version on the same OS; I also mentioned incompatibilities brought on by hardware differences between otherwise similar post-home computer systems.

But PC-BASIC takes this to a whole new level by having the potential of being incompatible with itself (!). If you run the program on Windows, it works as expected, even when using graphics modes. But if you try to install it on an ARM based Mac, it just won’t work. An alternative there is to install it as a module in Python and run it from the command line. But then the graphics modes won’t work. So you can’t expect everything to work similarly everywhere.

That being said, I like PC-BASIC. If for no other reason than nostalgia. Which, perhaps, all of what I have written here is.