The first programming language I ever used was BASIC. I was twelve or thirteen when a classmate introduced me to it. The first thing I tried making was a text-based choose-your-own-adventure game. I remember spending time composing an opening theme tune, fiddling with the commands to play sounds of various lengths and pitches. I spent ages creating a title screen with ASCII art, formatting the layout of the title screen just so. And I remember how overwhelming the many, many branches that each choice led to felt. What happens next? What happens next, here?

It was this experience that struck me, even then: that writing the story of the game was harder than the programming of the game; that code is a means to an end, not the end itself.

This perspective has stuck with me throughout my life. Was this the seminal experience that forever shaped my view of creating software? Or was this an innate personality trait of mine, and this just happened to be the first time I noticed it?

Soon after encountering BASIC, I was introduced to TurboPascal in a computing class in school. We were given an exercise in which we wrote code that drew some shapes on the screen. A red circle, a blue rectangle, a yellow square.

Whether it was the lack of interaction or the basicness (ahem) of what we’d made, but I remember being distinctly unimpressed: the language or commands we were taught didn’t lend themselves to any use that caught my imagination.

My next exposure to a programming language came a few years later. While learning how to make web pages I would view the source code of other sites, so it was natural that I came across Javascript. I would randomly copy and paste blocks of code and try to run them; I was often stumped by why they wouldn’t run. (Usually this was because I’d missed some onload attribute in the body tag.) By blindly modifying the values of variables to see how this changed the behavior of the program, I was able to fumble through figuring out how programming worked. This is basically how I stumbled into what would become my career.

BASIC has a unique place in the history of programming languages. Its proponents lauded it for how easy it was to learn; its detractors maligned it for corrupting the minds of those who learned it. These days it seems like a quaint old language up there with other languages that are spelled in all caps, like COBOL and FORTRAN. But reading Endless Loop made me realise that BASIC holds a different, much more central role in programming history than I’d realised. And the actual arguments for and against it are still alive and well today, they are just applied to different programming languages.

Conceived at Dartmouth University, BASIC was designed to be easy to learn. The creators’ goal was to make programming computers more accessible. A major part of this was to make it less hardware dependent. Programming languages of the time had to be modified to run on specific computer hardware, and BASIC abstracted away these hardware-specific internals.

BASIC became the lingua franca of early personal computers. It was baked into the ROMs of computers from every manufacturer. A whole cottage publishing industry sprung up around BASIC, with magazines and books filled with code listings meant to be typed into your computer. This couldn’t have happened if there hadn’t been a single language that ran on all personal computers of the time.

Ultimately, BASIC was outgrown. Industry and academia had their own reasons to abandon the language.

Academia rejected BASIC as not only unfit for purpose, but also as having a negative impact on those that learned it. In computer science, the concept of structured programming, the idea of separating code into functions, modules and namespaces, etc., was developed independently on both sides of the Atlantic. This was impossible to do in BASIC.

More outrageously, some computer scientists complained that BASIC tainted the minds of those who learned it, that anyone with formative exposure to BASIC would be unable to learn proper programming techniques.

(In fact, the “considered harmful” trope entered computer science in Edsger Dijkstra’s 1968 article Goto Statement Considered Harmful, which castigated the excessive use of GOTO and advocated structured programming instead.)

Personally, I’m not sure that I feel that differently about Java and OOP and their “tainting influence” when taught as a first language.

Industry seized newer languages and practices as well, but another interesting development happened as well: tools like Excel (and its predecessors), allowed non-programmers to achieve computing goals without needing to learn how to write full programs.

These days there are ever more tools that require little or no code to build complex automation.

Professional software engineers tend to look down at these tools, but this doesn’t mean that people aren’t achieving real-world results with them. For a long time, Javascript and front-end development were sneered at as not being “real programming”.

The parallels are instructive: BASIC was simple to pick up and you could it on any computer. I was able to learn HTML and then Javascript by viewing the source of pages I was curious about.

BASIC is no more, and with it we’ve lost more than we think, as David Brin puts it in his essay Why Johnny can’t code. Front-end development is not the same as when I learned it. Viewing source is no longer a viable way to learn how to make web pages.

Ironically, I now see junior software engineers prefer backend development, done in a single language, to front-end because “front-end is too complicated”.