pledged of $25,000pledged of $25,000 goal
0seconds to go
Funding Unsuccessful
The project's funding goal was not reached on Wed, December 29 2010 11:19 AM UTC +00:00
David WoldrichBy David Woldrich
First created
David WoldrichBy David Woldrich
First created
pledged of $25,000pledged of $25,000 goal
0seconds to go
Funding Unsuccessful
The project's funding goal was not reached on Wed, December 29 2010 11:19 AM UTC +00:00

Why Teach Programming with BASIC

In less than a century of programming, programmers have created thousands of languages, with dozens of popular languages in widespread use. Programmers and teachers have their choice of languages intended for industry or teaching, with specific languages designed for specific roles.

We've chosen as inspiration a language designed by Thomas Kurtz and John Kemeny: BASIC. BASIC exploded in popularity as computers became more accessible in the late '70s and early '80s. Everyone who's worked on ClubCompy started to program with BASIC, and it was an amazing introduction into the power of programming.

Since the introduction of BASIC in 1963, several generations of languages have appeared. Productive professional programmers have moved on beyond the simple BASIC of the '60s and '70s and early '80s, but we've chosen BASIC as our inspiration for its simplicity in two ways: it's easy to teach and it's easy to implement.

The Simplicity of Explanation

Kurtz and Kemeny designed BASIC for novice programmers. In doing so, they explicitly followed several design goals to enforce a simplicity of explanation:

  • A line is a simple statement

  • Numbers are numbers

  • Line numbers make control flow obvious

  • The default behaviors are obvious and reasonable

While it's possible to emulate some of these features by implementing a subset of a language such as Scheme or Smalltalk, the designs of those languages rely on the gestalt of the languages: a subset of Smalltalk is less useful than it could be unless you choose the very heart of Smalltalk.

Similarly, BASIC's relative lack of abstractions is an advantage to people who've never programmed before. A sequential list of instructions with no control flow more complex than a loop or "go to step 10" is much easier to understand than even simple function application (let alone method dispatch or recursion).

Function application, method dispatch, and recursion are important concepts to understand to be sure, but we prefer to delay their explanation until later in the ClubCompy learning experience.

Like BASIC in the microcomputers of our childhoods, ClubCompy's language offers a tight integration with the shell. Any expression usable in the shell is usable in a program, and vice versa. The only difference between a program and immediate commands is the presence or absence of line numbers. Again, this is easy to explain in metaphor terms that students already understand.

Finally, the limitations of BASIC help us write good tutorial materials because they limit the complexity of the programs we write. Where languages with better possibilities for abstractions allow us to write very concise, very powerful code, we must be more explicit and less clever here. Our goal is not to write the most elegant programs possible in any language. Our goal is to write programs to help our students understand computing.

The Simplicity of Implementation

Didactic concerns drive the design, but implementation concerns are also important. A beautiful, elegant language that students find impenetrable and unusable is as useless as the best teaching language possible that we cannot implement effectively. We've spent a lot of time designing a language that is both simple to teach and sufficiently simple to implement.

Our particular technical constraints offered their own limitations:

  • We wanted a system hosted solely in a modern web browser. We can make few assumptions about the computers our students will use, especially those found in homes and libraries. Requiring the installation of extra software, even plugins, is a barrier we prefer to avoid. This meant creating a new language implementation.

  • We wanted a system easy to secure, such that there are no mechanisms to escape the security of the system to manipulate either the underlying machine or the experience of other users. In this case, a language with fewer features and fewer possibilities for abstraction and cleverness is easier to audit. This meant evaluating our implementation for potential mischief.

  • We wanted a system which runs on multiple platforms. Again, we make no assumption about the underlying machine besides the presence of a relatively modern web browser. You can access ClubCompy on a machine running Microsoft Windows, Mac OS X, a free software system running the Linux kernel such as a GNU/Linux distribution or an Android smartphone, and even certain set top boxes and game consoles.

  • We wanted a system with intrinsic graphics primitives. This justification follows one of our goals for teaching: students should be able to produce visual feedback within the first three minutes of exploring ClubCompy. Intrinsic primitives for drawing and sprite operations are easier to explain than the extension ecosystem necessary to import graphic primitives from a library.

  • We wanted a system we could tweak and change for further didactic purposes. When we added the turtle graphics operations, we gleefully borrowed them from other languages we've used. The Logo programming language, created in 1967, eventually introduced the turtle first as a physical robot and then a cursor, and influenced multiple generations of didactic languages. We implemented our own version of BASIC, and in an already-fragmented world of many, many implementations and reinventions of BASIC question that. If we'd borrowed and reimplemented and then expanded Smalltalk, for example, we'd have had to do more work to understand and adhere to the core principles of the language. BASIC frees us for further expansion.

Even though the Tasty language of ClubCompy is an amalgamation of BASIC and Logo, there are no strict technical reasons why it must remain so. Nor do any technical reasons exist why the Tasty language must be the sole language of ClubCompy. We've designed our technology such that many languages are possible, such that we can create new languages and implementations with all of the capabilities of the Tasty platform with different syntaxes.

Why would we do this?

Just as BASIC makes introductory programming more obvious, Scheme makes function application and recursion more obvious, and Smalltalk makes message passing more obvious, the philosophy and syntax of a language influences the mindset of its programmers and the design of programs written in that language. Perhaps future ClubCompy lessons will require the design of new languages to expose didactic concepts in concrete and effective ways.

After all, our goal is to promote the understanding of computing and logical thinking and problem solving far more than the syntax or implementation of any one system.


Only backers can post comments. Log In
    1. David Woldrich Creator on

      Ol' Reliable: Sorry you are frustrated, but please no cussing.

      We have a System Guide which attempts to capture the supported keywords. IF is one of them. PRINT and PRINTLN are also supported keywords.


      There is a documentation panel on the Compy Shell that you can get to by mouse clicking on the book with a question mark on it (look to the bottom-left on the browser window). That panel provides links to the public resources we've got for you to look at so far.

      Of course we will be developing a full Programmer's Guide which will be more comprehensive and kid friendly, stay tuned.

      Dave Woldrich

    2. Missing avatar

      deleted on

      Well, shit. Does your BASIC even support an 'IF' statement?

    3. Missing avatar

      deleted on

      You really need a language reference, like the one that came with QuickBASIC. I'm trying to figure out how to PRINT without printing the terminating newline. In Microsoft BASICs, this was always done by adding a semicolon to the end of the statement, which you could find out by looking at the entry for "PRINT" in the Language Reference.

      Well, at least you remembered that the question mark was an alias for PRINT.

    4. Missing avatar

      grappelli on

      I started with Applesoft BASIC when I was eleven ... I'm just shy of thirty now, and though I favor Perl these days, it'll always have a place in my heart.

      To anyone interested in learning, I'd suggest BASIC, QBASIC, maybe Visual BASIC, and then branch out. Walk before you run :)

    5. Eric on

      I would like to see a local client. (in a cross platform language so that it will work on all computers) My children do not have internet access. The internet is too dangerous for children. I install everything onto their computer for them.

      Also regarding GOTO: this is how computers work at the machine language level, if we don;t let our children learn how it works from the beginning they will have a harder time learning assembly. If you want to raise an entire generation of Java/C# developers and have no assembly developers left, then go ahead and eliminate exposure to GOTO. I for one am not holding anything back from them.

    6. Missing avatar

      Mark Randall on

      I learned programming on ROM-based BASIC in 1980 on a 4K home computer. It was a great foundation. From there I went to assembler (the only alternative choice) and from there to C. I think it's a pretty good language to start out in and I agree with the point that more advanced languages entail harder concepts that are out of scope for the initial learning experience. I do think that BASIC can be improved for this purpose. In fact there were many improvements and flavors of BASIC over the years that can be mined for useful concepts. I particularly liked DO.. WHILE.. UNTIL. There was also a nice implementation that enabled calling a named block of code and returning a variable. This gets around some of the problems mentioned by other posters because it becomes possible to write modular programs with no GOTO statements at all. However, I don't think it's necessary to eliminate GOTO from the command set. In fact it could be a nice instructional goal to have students realize that GOTO results in structural problems in larger programs and then progress to named modules. Then they'll really learn the fundamental *why* behind the advantages of modularity.

      I also suggest looking at Scratch and other similar efforts as I think they have some nice aspects such as graphically showing FOR.. NEXT type loops. I think a lot of advantages could be realized in the programming interface itself such as having commands change to a different color upon being typed. This will help reduce typos and confirm to the student that they've remembered the command name.

    7. Matt Quigley on

      I believe the commenters above are a somewhat brainwashed into believing BASIC is bad, and therefore should not be taught. It is, in fact, very easy for someone who has no experience in programming. I have no idea what amaro means by saying it has distorted logic. GOTO is not distorted, it is the most straightforward control structure there is. Not being able to convert your own ideas to BASIC code is probably a fault of a beginner, not BASIC's fault. Colin Tree mentions no reason why it was horrible to use, and the difficult to debug and too slow comments are completely inconsequential to a beginner's programming course; "slow" and "debugging" has no relevance to a student who has never programmed before.

      Regardless of your experiences with other languages, it is incredibly easy to get code running in a BASIC environment. To make a Hello, World! application is extremely straight forward in BASIC. To do so in Java, one has to know about file names with class names, the compiler, and other issues. Similar problems with other languages such as C. In BASIC, type the statement and then type run. Or, imagine the steps needed to draw a line in Java. There is a lot of overhead to get to the point of being able to draw a line on a canvas, which will probably involve the teacher creating a test harness with lots of code the student doesn't understand, and then a comment in the code such as "// Put your line drawing code here". In BASIC, you can just type DRAW LINE and the line is drawn without any other overhead.

      Obviously, BASIC fails to be the optimal language when getting into more complicated matters such as object oriented programming and structures. It should be expected that a student can and should learn more than one language, so moving on to another language once the beginner's course is finished is fine, IMHO.

    8. Henk Jurriens on

      Two weeks ago, I gave a HTML5 workshop to high schoolers in the Netherlands. No experience required and we had a lot of fun! (html5gamejamworkshop.appspot.com)

    9. Missing avatar

      Colin Tree on

      As a Forth programmer one cardinal rule is
      "Thou shall not goto"
      call / return and other proper structures
      I did a short time with Basic because
      that was what was commonly, freely available
      but it was horrible to use, difficult to debug and too slow.

    10. Missing avatar

      amaro on

      Personally I never could understand why BASIC is called "easy language". It was an introductory language at my University and I never could understand its distorted logic. Actually, trying to learn it gave me a bad start in the programming. And it wasn't until I've discovered Python [which was my real teacher] I could see the beauty of converting own ideas into meaningful actions from the computer. I think resurrecting BASIC for educational (or any) purposes is just wrong. Would you stuff your kids with french fries and hot dogs having option of introducing them into refined Mediterranean diet?