End passive consumption! Kids can create, play, and learn on computers with a subscription to ClubCompy. Read more
This project's funding goal was not reached on .
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.