BRINGING UP
BASIC


by John G. Kemeny and
Thomas E. Kurtz

"Yeah. Well, see, these computer firms are very awkward. Al the smaller personal computers use BASIC, because it's the easiest language and also one of the best. But the firms making them all build in their own variations, so that if you record your programs from their machines, you can't run them on anyone else's. That keeps you faithful to them in the future, because if you change to another make, all your tapes will be useless."
    "What a bore," I said.
    -Dick Francis, Twice Shy (G. P Putnam's Sons, New York, 1982)

John G. Kemeny and Thomas E. Kurtz, the originators of BASIC, are the authors of Back to BASIC.

Ever since we invented BASIC, over twenty years ago, we've used it almost exclusively for our own programming. Most others at Dartmouth do also. Students in the beginning computer science courses use it to learn with.
    Persons outside Dartmouth may wonder what we're talking about. BASIC a language of computer science? Aw, come on! But stick with us for a minute. We can explain. The BASIC we use at Dartmouth is a far cry from the slangy street BASICS used by the rest of the world. In the past twenty years we've brought up our own BASIC to be a good citizen and to show some class. The less fortunate BASICs picked up bad habits and vulgar language. We would no sooner think of using street BASIC than we would think of using FORTRAN!
    In the early 1960s there were no personal computers, or even time sharing, to be found outside the research labs. If you wanted to do computing, you had to punch up your programs on cards, carry them to the nearest computer center (for us, until 1960, it was a 135-mile train ride), then wait hours (or days) for the results.
    We wanted our students to learn about computing without having to endure such problems. Drastic action was called for. So in 1963-64 we designed and built a time-sharing system, which later became the backbone of the General Electric Time Sharing network. It was a system meant to be easy for ordinary people to use, and one of its ingredients was the new language BASIC.
    The design goals for BASIC included ease of learning for the beginner or occasional programmer, hardware and operating system independence, the ability to accommodate large programs written by expert users, and sensible error messages in English.
    As the years went by, our infant BASIC grew up. It learned about character strings and files and matrix operations. By 1971 our local version included subprograms that could be collected into libraries and stashed away for later use-by anyone. It knew about both character and random access files. For the times, BASIC was a pretty advanced language.

Thomas Kurtz and John Kemeny

    In the early 1970s it learned how to do interactive graphics, and graphics statements became part of the language itself around 1975. The level of sophistication even then was superior to that now found in many commercial BASICs. Our users did not have to know how many dots were on the screen: the pictures could be drawn in user coordinates. You'd think this idea would be obvious by now. But today's users of Microsoft BASIC have to know that there are 320 dots horizontally and 200 dots vertically (if you're using medium-resolution color graphics on the IBM PC) and have to do messy arithmetic to draw simple pictures. We even had picture definitions, which are like subroutines but draw pictures instead. The pictures can be shifted left or right, shrunk or expanded, and even rotated.
    Edsgar Dijkstra got the ball rolling on structured programming in the late 1960s, but not until the early 1970s did his ideas reached the hinterlands. In 1976 we added structured constructs to our BASIC. Incidentally, there were virtually no problems converting from old-fashioned BASIC to Structured BASIC. We dropped the GOTO statement overnight, with no regrets. Our students could not have cared less. We told them not to use it, and they didn't.
    So the BASIC in our family was a sophisticated language with a good collection of structured constructs, sophisticated graphics, all the good modularization tools, etc. What a far cry from what most of the rest of the world had to use.
    We got our first inkling of the sorry state of BASIC's affairs when, several years ago, one of us used a personal computer for the first time. It was an Apple II Plus, and we were converting programs that ran on our big machine into Applesoft BASIC. We were appalled at what we saw. Microsoft, the authors of Applesoft, advertised multicharacter variable names, but used only the first two characters. There was no way to use lower-case letters. There was no way to indent programs to show structure. There was no nice way to have comments appear together with a statement on the same line.
    To give you an idea of how others had prostituted our beautiful language, they arranged for the for-loop always to be executed once, as in

FOR I = 1 TO N
...
NEXT I

when N is 0. Shades of FORTRAN! We thought we'd banished that quirk over twenty years ago, and here it popped up again.
    Even worse, we discovered that the following statement was completely illegal:

IF B = A THEN 500

This statement was interpreted in Applesoft's prescan as

IF B = AT HEN500

which is, of course, a syntax error. Ugh!
    Several years later, we discovered an equally ugly version of BASIC on the IBM PC. We were horrified by many features that required knowing intricacies of the hardware. Not only did graphics necessitate counting dots, but IBM had two graphics modes (for color) and a program written for one would not work in the other!
    What about our original goals? We agree that most people find street BASIC fairly easy to learn, provided they can read what they've programmed. That's not so easy with only upper-case letters and often no ability to indent the code to reflect what is going on. In addition, street BASIC has its own idiosyncrasies. For instance, this dialect persists in telling the beginning student:

SYNTAX ERROR IN 150

Isn't a "syntax" a levy on cigarettes or alcohol? We certainly can do much better than that. But street BASICS don't.
    With all this complaining, you might ask, what are we doing about the sorry state of affairs? Well, first of all, we've been working with the ANSI committee that is coming up with a standard BASIC. This committee is now, thankfully, nearing the end of its work after ten years. The standard BASIC they are developing is a rich language, with structured constructs, nifty graphics and a wide variety of other features. Some say there are too many features, but it's an easy matter to pick and choose the ones you want and ignore the rest.
    Also, we were struck by the Pascal experience. We had sat back at our institution and bragged about our BASIC, and then wondered why no one paid attention. Pascal enjoys its popularity today not solely because of its clean design, which is an undeniable feature, but because the folks at the University of California, San Diego, produced and promoted a commercial-quality implementation of the language.
    The old adage "If you want something done right, do it yourself" finally dawned on us. When the opportunity arose in the spring and summer of 1983 to form a company to produce a definitive version of BASIC, we jumped at the chance. We call our product True BASIC TM. It closely follows the proposed (as of this writing) ANSI standard for BASIC. True BASIC also embraces the good things we have demanded from our own versions of BASIC over the years: good and accurate error messages, a user interface that is simple and plain, and the capability to be used for both small and large programs.
    True BASIC will be produced to fit into the major personal computers that have a reasonable amount of memory (128K or more), and it will be identical for all machines. Teachers can assign exercises without worrying about which computers are currently in the computer lab. Schoolbook authors will be able to write in True BASIC and have their programs run on all the major personal computers. They can leave the worry about the peculiarities of the hardware to us.
    Our "tapes" will no longer be useless. They will run on any machine. We hope that we will make Dick Francis happy, at last.

Studens at Dartmouth


Return to Table of Contents | Previous Article | Next Article