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.

This quote is from Edsger Dijkstra in a short article he wrote in 1975 called “How do we tell truths that might hurt?”.

Dijkstra had the reputation of being facetious and it’s hard to tell whether he really meant this or if he was just poking some harmless fun at the various technologies in vogue in 1975 (a practice I can certainly relate to). Whatever the case may be, his quote has been picked up and reproduced literally quite a bit, often by people trying to engage in some language snubiness warfare.

Personally, I think this quote is completely and unequivocably wrong.

Most of the developers that I know or that I have interacted with and who are in their thirties or above have, obviously, started with BASIC. A lot of them are very good engineers, and not just at one language in particular, but also very knowledgeable about the technology. They routinely write code in several languages and they are also very comfortable with peripheral notions such as databases, clustering, parallelism, etc… You name it. All of them would agree that while BASIC was quite primitive, it was also a great enabler. It allowed you to get things running on the screen very quickly and there is no doubt that it created an entire generation of people who became absolutely passionate about the field of software engineering.

BASIC should receive praises for this fact alone. But let’s not stop there.

Was BASIC really that primitive? Looking back in the days, I would say “far from it”. Granted, at the time, some languages were beginning to push structured and OO programming into the industry, but for a mainstream language that was available on every single computer that was sold at the time, I am tempted to say… “Loops, variables, rudimentary math and graphical functions… not bad!”.

I would also argue that every argument that you can make against BASIC can be made against assembly language, and in worse ways.

Is there anyone who thinks that assembly language corrupts the mind of programmers beyond redemption? Certainly not me. Most developers who learn assembly language will quickly move on to higher level languages while retaining a very accurate mental model of what’s going on under thehood, which is a win-win situation in my opinion. Just because you know the difference between stack and heap and you still remember a few hexadecimal opcodes from your favorite microprocessor doesn’t mean you won’t be able to understand classes, polymorphism or closures.

I certainly loved my time writing BASIC, and while it ignited my passion for this industry, the epiphany for me came in a slightly different form.

Story time.

In the first year with my ever beloved Apple ][, I was writing a lot of Applesoft BASIC but probably reading even more of it. Back then, there was no Internet and magazines were few and far between, so I took any opportunity I could to read code.

At some point, I came across a mysterious instruction called “CALL 768”. I had read the documentation for this CALL instruction but I still didn’t understand what it did. Puzzled, I typed “CALL 768” at the prompt and something magical happened: the computer played a short tune.

Obviously, I knew the Apple ][ could play music but I was startled to discover that you could do so with such a simple command. I quickly added it to my own program and I was delighted to find out that it worked. A few days later, I resumed working on my program but as soon as I launched it, it froze. I quickly identified “CALL 768” as the source of the problem. I started suspecting that the previous program I was investigating had put something in memory, which was wiped when I turned the computer off. To verify this hypothesis, I launched this other program, then launched mine again and this time, it worked.

Mystery solved.

Well, partially. My curiosity was piqued and now, I just had to figure out what was going on. I started wondering where in the memory this code could be. It obviously wasn’t in BASIC since a LIST didn’t show anything. My (still quite nascent) hexadecimal knowledge kicked in and I realized that 768 was $300 in hexadecimal. I had some rudimentary knowledge of something called the “Monitor”, which allowed you to read machine language. I was, however, unable to really understand it, a bit like knowing the Hiragana alphabet, being able to pronouce the words that Hiragana symbols form but being unable to understand them.

The instruction to start the monitor was “CALL -151” (mmmh… there’s this CALL instruction again). Once there, you can see the content of the memory by typing the address followed by “L”. Feverishly, I typed “300L” and sure enough, an assembly listing was there. I rebooted, checked the location again, the assembly was gone. I ran the other program and the assembly returned. I didn’t know how the assembly went there (I would investigate this later) but I knew I was well on my way to figuring this puzzle out.

It took me several days of painful trials and errors, but this little investigation led me to take my first steps in 6502 programming and more importantly, to understand how BASIC and assembly language could interact with each other. The realization that BASIC could read and write memory with PEEK and POKE was the last missing piece, and this understanding blew whatever was left of my mind at the time. I was just amazed at how beautiful this orchestration was, and how all the pieces fitted so neatly together.

That was it. This is what started the passion in me. It wasn’t a language, it wasn’t a specific hardware or a concept. It was the realization that despite all the apparent magic, everything was logical and no mystery could resist meticulous investigations and logical thinking. I still felt like a complete beginner but at that moment, I knew that given enough time and effort, I should be able to puzzle it all out. And maybe be able to create all these wonderful programs that I had been using so far without understanding much of how they worked.

BASIC had very little to do with it. It was never about BASIC, it was always about the magic.