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 recursio