Originally published on: Sun, 13 Mar 2011.
“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” – Edsger Dijkstra
My early days of computing began in the late 1970’s. I used to go in to the Radio Shack in the mall where they would let the patrons type stuff into their display-model TRS-80. You could tell that none of the patrons were skilled in any type of computer language as the screen was filled with a line of nonsense followed by a line indicating that a syntax-error had occurred.
I had wondered just exactly what one would have to type in to make the computer actually do something.
A short time later, my eldest brother had told us that he’d bought a TRS-80, so we went over to see it. He had a few interesting programs on cassette that he demonstrated. However, the program that captured my attention was one that he quickly typed in. It went something like this:
It’s a relatively simple program. It clears the screen, displays text on the bottom line of the screen, then continuously plots points based on two random coordinates. All but the last line of the screen starts to fill with little rectangular blocks:
After he demonstrated more programs, I was left alone with the computer and was tinkering a bit. I tried to re-type the above program from memory, but I didn’t know the exact syntax. I was typing a lot of things in an English-like language such as:
20 X = A RANDOM NUMBER FROM 1 TO 10
While it didn’t work, it took me almost no time to learn how to edit and list a program by using line-numbers at the beginning of each line.
I tried all sorts of combinations and then began to consult the manual. My brother returned and re-typed the program. I saw my mistakes.
At that point in time, I decided that I was going to learn the BASIC programming language.
BASIC is an acronym for Beginner’s All-purpose Symbolic Instruction Code. A dialect of BASIC was available on just about any 8-bit era home-computer produced in the United States and the United Kingdom.
While not terribly expressive as compared to other programming-languages, BASIC had a few attractive features:
- BASIC programs were compact enough to allow for fairly elaborate programs to be developed on computers with minimal Random Access Memory (RAM).
- BASIC could be learned easily by hobbyists; it was an entry-level programming-language.
- BASIC was interactive; one could stop a program at certain points, examine/change variables, restart the program at any line-number …etc.
- BASIC editors were a part of the language and were easy to understand.
- Early computers had no operating-systems. BASIC was the operating-environment.
BASIC began to get a bad reputation because of slow performance. This really isn’t due to any aspect of the language itself; the early implementations of BASIC were constrained by hardware that had small amounts of RAM. Early BASIC interpreters did not have the luxury of being able to cache important information such as target line-numbers or variable addresses. The interpreters used to continuously re-examine each line even in a series of lines that would be repeated throughout the program.
So, BASIC acquired a reputation for being slow.
BASIC was also taken to task for promoting “spaghetti code” due to the necessary use of the GOTO verb for flow-control.
Due to the amount of RAM available at the time, BASIC also limited the names of variables to one or two characters. Subroutines were numbered instead of being named. All variables were global in scope, limiting the ability to modularize and re-use code. Many cited these elements common to most BASIC’s as making programs unreadable.
To further paint a bleak picture, wise programmers began to use BASIC as a sort of object-code. They would take advantage of the behavior of the interpreter to speed up their programs at the expense of limiting the readability of the code.
Techniques used included:
- Placement of all subroutines at the beginning of a program so that GOSUB would find them more quickly.
- Packing lines together with no spaces between words to speed up the interpretation process.
In 1980, my dad received a TRS-80 pocket computer as a gift.
At this time, my Geometry teacher had purchased a TRS-80 for students to use. He financed the computer by selling candy bars. The last portion of our school day was essentially a study-hall. My teacher used this time to teach a non-credit BASIC programming class.
I loved the class. One of the challenges was to write a program that would find all factors of an input integer. I wrote that program and others on the pocket computer. The pocket computer only had about 2K of RAM and had a single-line display, but I managed to write a couple of simple games for it using a random-number formula that was provided in the manual.
I decided to write an arcade-style game in BASIC for the desktop TRS-80 computer at school. I borrowed a manual and went about the seemingly simple task of animated a flying spaceship. I wanted to move it across the screen vertically.
I spent hours trying to figure out how to SET() and RESET() points on the 128 by 48 pixel viewing area in a way that would allow me to animate the spaceship. At this time, I knew very little about arrays or screen-memory or anything that might help me out. In fact, I knew very little about programming. I was trapped by the commands and simple control-flow available to me.
I asked my brother about how this sort of thing was done. He referred me to machine-language which is another story.
I gave up the project at the time and was content to continue with the classes at school.
In the latter part of 1982, I received my own TRS-80 Model I desktop computer.
The computer was purchased at an auction and came with a number of books on BASIC. I went through all of them. It was much easier to experiment now that I had a fairly powerful BASIC and 16K of RAM!!!
I began to buy ( and borrow ) issues of 80-Micro magazine. I typed in a number of the BASIC listings and studied many others. I read a lot about other languages, but I was very confused about them. I couldn’t understand why they didn’t have line-numbers by each line when the source-code was printed in the magazine. I had been limited to a line-oriented editor. I didn’t understand how one ran these programs, either. Did one simply have to type RUN at some prompt?
I spent a lot of time writing and debugging programs. Debugging was a skill that I learned because of BASIC. BASIC was easy enough for the neophyte to write, but debugging took patience.
At this time, I was taking a BASIC class in high-school using Apple II+ and Apple IIe computers. The Apples had high-resolution graphics and nifty BASIC primitives that allowed one to draw all over the screen.
I soon learned Z-80 and 6502 assembly-language and began to move outside of the BASIC box where I had been confined.
In 1983, I began working with Commodore PET and Commodore 64 computers in an independent-study course at my high-school.
I soon bought my own Commodore 64.
The C64’s BASIC was as spartan as it’s predecessors. This helped to ensure compatibility. Often, one could write BASIC programs that could run unchanged on Commodore’s VIC-20, 64, and PET computers. However, software became available for various computers that would add extensions to the BASIC language.
I had the opportunity to use Simons’ BASIC ( see the Wikipedia article here. )
Among the 114 new commands added to BASIC was a set that added an ELSE verb to use with IF statements, named procedures, local variables, and other elements of structured-programming normally found in languages such as Pascal.
I began to understand the limitations of BASIC and turned to other languages like Pascal and C.
At this time, home-computers were evolving and BASIC implementations followed. BASIC implementations on these new computers often provided structured-programming support and optimizations to the interpreter for better execution.
It appeared, though, that many programmers who used computers such as the Commodore Amiga were turning to compiled languages such as C to better exploit the potential of their machines. Newer dialects of BASIC and BASIC compilers began to take over the landscape. Line-numbered / GOTO-laden BASIC was fading off into the sunset.
It’s difficult to argue with Dijkstra’s quote that appears at the beginning of this post. I cannot accurately state that I would be a better or worse programmer now if I had avoided BASIC altogether. Others have stated that the quote was supposed to be mildly in jest.
Dijkstra was a prominent figure in computer science, however. I do not take his words lightly. I would infer that it might be more difficult to teach someone who had only been exposed to line-numbered BASIC, but to suggest that they were beyond hope baffles me.
I look at BASIC as an entry-level vehicle to the art of programming. It was approachable. Back in “the day” many who had no intention of becoming programmers were conversant in BASIC. I would argue that BASIC inspired many. Like many of my generation, I moved on. I studied the contemporary languages and practices of the day and rarely went back to using BASIC. I look at BASIC as a necessary milestone; something that jump-started my entrance into programming. I learned much from BASIC. I learned why I need to avoid certain practices.
I have pondered what would have happened if I had been able to avoid using BASIC in those early days. Would I become “mentally mutilated beyond hope of regeneration” ? I don’t think so. I think that the path I took was the proper one, for me.