To appear in the Proceedings of the 43rd ACM Technical Symposium on Computer Science Education, SIGCSE 2012 Calico: A Multi-Programming-Language, Multi-Context Framework Designed for Computer Science Education Douglas Blank1, Jennifer S. Kay2, James B. Marshall3, Keith O'Hara4, and Mark Russo1 1 Computer Science Department Bryn Mawr College Bryn Mawr, PA (USA) (1) 610-526-6501 dblank@brynmawr.edu 2 3 4 Computer Science Department Rowan University Glassboro, NJ (USA) (1) 856-256-4593 Computer Science Department Sarah Lawrence College Bronxville, NY (USA) (1) 914-395-2673 Computer Science Program Bard College Annandale-on-Hudson, NY (1) 845-752-2359 kay@rowan.edu jmarshall@slc.edu kohara@bard.edu ABSTRACT The Calico project is a multi-language, multi-context programming framework and learning environment for computing education. This environment is designed to support several interoperable programming languages (including Python, Scheme, and a visual programming language), a variety of pedagogical contexts (including scientific visualization, robotics, and art), and an assortment of physical devices (including different educational robotics platforms and a variety of physical sensors). In addition, the environment is designed to support collaboration and modern, interactive learning. In this paper we describe the Calico project, its design and goals, our prototype system, and its current use. Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – computer science education. General Terms Design, Experimentation, Languages. Keywords CS1, computer science education, integrated development environment, IDE, pedagogy, programming languages, robots. 1. INTRODUCTION Today there are many new and exciting programming environments and contexts available for learning about computing. For example, Alice [8] and Scratch [10] provide drag-and-drop, nosyntax-errors programming environments, and DrRacket (formerly DrScheme) offers an award-winning integrated error display and logging system for Scheme [11]. Likewise, there are many exciting pedagogical contexts for learning about computer science, including media computation [6], story-telling, game development, AI, robotics, visualization, and art. Unfortunately, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGCSE’12, February 29–March 3, 2012, Raleigh, North Carolina, USA. Copyright 2012 ACM 978-1-4503-1098-7/12/02...$10.00. these contexts are often tied to a specific programming environment, which limits their availability to only those willing to work in that programming environment. Similarly, picking a specific programming environment often limits which contexts one can explore. Ideally, educators should be free to choose the most appropriate programming languages and, independently, the most appropriate themes and contexts for their courses. The choice of programming language should not limit the context, nor should the choice of context limit the programming language. The Calico project is designed to provide a single framework for multiple programming environments and multiple contexts so that instructors and institutions need not limit their pedagogical choices [3]. Thus, within a single framework, teachers can smoothly transition students from one programming paradigm to another. For example, perhaps an instructor would like students to begin with a Scratch-like language [16] and then move to Python. Or perhaps the instructor might wish to start with Python and move to Scheme. Both of these transitions are possible in Calico without changing the computing context, whether it be art, game development, visualization, or any number of other possibilities. Calico comprises four main components: an interface for multiple programming languages; an interface for multiple libraries for exploring different computing contexts; an interface for peer-to-peer communication; and an integrated editor. The language interface allows for the execution of individual language expressions or entire program files, and for the sharing of data and functions across languages. The library interface enables program modules to appear as native objects within all of the available languages. This provides a foundation for exploring computing contexts, such as graphics and robotics, in a language-independent manner. The communication interface provides functionality that enables users to easily exchange information among themselves. Finally, the editor provides a common framework for editing programs in any language, be it graphical or text-based. We have developed a prototype version of Calico (Figure 1) that provides well-tested support for the Python programming language and a personal robotics context (called Myro) for introductory computing, as well as preliminary support for several other languages and contexts. Calico runs on Linux, Macintosh, and Windows. This paper describes the prototype version of Calico, which is currently being piloted in five Fall 2011 CS courses, as well as our broader goals and vision for the system. In the ongoing development of the Calico framework, our overall goals are to “raise the ceiling” by including a variety of more sophisticated pedagogical contexts and programming languages, to “lower the floor” by including support for an intuitive Figure 1: Prototype of the Calico shell (left) and editor (right). visual programming language for beginners, and to “widen the doorway” by including contexts beyond those typically found in traditional computer science, such as scientific visualization and art. As an example, the following Calico Scheme program defines a recursive function for testing whether an integer is even: scheme> (define is-even? (lambda (n) (cond 2. A MULTI-LANGUAGE ENVIRONMENT Users interact with each supported language through the Calico Shell. The shell provides a place for text-based language expressions to be entered and evaluated interactively, with the results available for immediate inspection. In many ways, the shell is very similar to other interactive interfaces, such as IDLE, DrRacket, Jython Environment for Students (JES), and many others going back to the read-eval-print loop of Lisp. However, Calico offers three significant improvements over these other interfaces: Calico is completely language-agnostic, users can easily switch between a variety of available languages, and different languages can share data and functions. Our Calico prototype currently fully supports Python as a scripting language for students to use. Beyond support for Python, there is preliminary support for Ruby, F# (similar to OCaml), Boo (Python with types), and Scheme. The shell is language-agnostic in that it is not tied specifically to any programming language. Languages are dynamically loaded on startup through a simple, standard interface. Once Calico is started, users may switch between loaded languages through a simple key combination (e.g., Control+5 might be Python, and Control+6 Ruby). Of course, most users will probably only use a single language at a time; however, users can mix data structures and functions from different languages together. Furthermore, the sharing of data and functions requires no extra overhead. For example, data need not be “marshaled” (or copied) in order to be accessed by different languages. In addition, functions defined in one language appear native to each of Calico’s supported languages, even if they involve very different types of execution mechanisms. ((= n 0) #t) ((= n 1) #f) ((< n 0) (is-even? (- n))) (else (is-even? (- n 2)))))) Ok In this example, is-even? is local to Scheme. However, this function can easily be made available to other Calico languages. The following code adds the function even to the global environment, turning the Scheme function is-even? into a function callable from other Calico languages: scheme> (define! even (func is-even?)) Ok The user can then dynamically switch to Python, and call the even function as if it were a native Python function: python> even(9998) True Conversely, functions defined in Python can be utilized by Scheme programs in a similar fashion. However, an essential aspect of Calico's Scheme implementation (and most others, as well) is that it is properly tail-recursive. The effective depth of Scheme's call stack is limited only by the amount of system memory available, unlike in many other languages, such as Python or Java, which impose a limit on the maximum depth of the stack. Other Calico languages, however, can take advantage of Scheme's flexibility. For example, the above even function called from Python will work for arguments of any size, whereas a function defined in Python equivalent to is-even? will crash for arguments above a certain size, depending on the depth limit of Python's call stack, even though the function is tail-recursive. (The argument 9998 shown above, for instance, causes CPython 2.7.2 to crash.) In fact, whether or not a function is tail-recursive is irrelevant, since Scheme imposes no limit on the recursion depth either way. This example shows that Python can directly exploit the power of Scheme in Calico. In addition to supporting a variety of different languages, Calico makes it easy for educators to modify either the syntax or semantics of a language, or to create a completely new language. Both of these options have been largely unavailable to educators in the past. Because a language is a plugin, and is written in the same manner as any Calico library (discussed below), adding a new text-based or graphical language is a simple matter of adding a single file to the system. This file defines what to do when Calico is asked to evaluate a snippet of code such as an expression or group of statements, and also what is necessary to run an entire program file. Additional functionality can also be included if desired, but little else is necessary for the language to appear in Calico’s menu. To fully integrate the language into Calico, the system needs to define a method for accessing the global environment that is shared across all languages. Calico incorporates a layer for language designers called the Dynamic Language Runtime (DLR). This layer is an open source set of functions to help designers create programming languages using modern techniques [4]. Open source versions of Python and Ruby have already been developed using the DLR. This layer is also the mechanism that allows Calico’s languages to share data and functions. The syntax and semantics of Calico’s version of Python has been refined for pedagogical purposes. For example, the print function of Python 3 has been selected over the print statement of earlier versions, and Python’s new with statement has been included. Of course, these are minor changes, but instructors have the ability to change any aspect of a language in principle. This gives instructors fine-grained control over the languages they use, and frees them from having to rely strictly on the choices made by language designers. Of course, this could potentially have adverse effects, by splintering a language into many incompatible versions. On the other hand, this could allow new variations of a language to emerge that would not otherwise be possible. 2.1 A Visual Programming Language To demonstrate the flexibility of the Calico system to incorporate new languages, we are developing a blocks-oriented, drag-anddrop visual programming language for Calico called Jigsaw (Figure 2). This new language will closely follow the lead of Scratch [16], a visual programming language primarily for children from the Lifelong Kindergarten Group at the MIT Media Lab. Visual programming tools like Scratch have been very successful at making computer programming accessible to K-12 and undergraduate students [9]. Students will be able to execute a Jigsaw program directly in the graphical environment with the built-in Jigsaw language interpreter. Alternatively, the system will be able to translate a visual program into the equivalent source code for several textual lan- Figure 2: The Jigsaw visual programming environment. guages integrated into the Calico environment. The translator will build a bridge from the high-level programming concepts represented by Jigsaw blocks to specific language implementations. The student will thus be able to see directly how an abstract programming concept can be expressed concretely in multiple ways. Jigsaw will include block palettes that encapsulate the rich array of computing contexts available to all Calico programming languages. Calico’s common environment and shared libraries will greatly facilitate the integration of new contexts as Jigsaw block sets, as well as the process of translating a Jigsaw program to the equivalent source code in multiple textual languages. Jigsaw will be extended in several ways to further enhance students’ ability to visualize computer programming. Graphical extensions to Jigsaw will include interactive design and manipulation of data structures, a stepping debugger with the ability to inspect and modify multiple levels of execution scope within a Jigsaw program, and a facility to create and deploy code-yourown blocks for others to use. Experience has shown that new students often cling tightly to the syntax of the language that they are learning. So one may not want to expose introductory students to too many languages at once. We suspect, however, that starting with a visual programming language and migrating to Python in CS1 would be beneficial to students. This hypothesis can be easily tested with Calico. 3. MULTI-CONTEXT COMPUTING We consider a context to be a unifying theme used to drive student motivation. A context should be supported by well-designed curricular materials and libraries, and perhaps also by appropriate physical devices. Currently Calico supports two contexts: the Myro robotics library for the Scribbler robot with the IPRE Fluke extension [2, 14, 17], and a 2D Graphics library with optional support for physics simulations, including gravity. A Calico library only needs to be written once, but appears as if it were implemented for each of the supported languages. For example, the Myro library appears as a native Python module inside Python, as a native Ruby module inside Ruby, and so on. We have written programs in several languages using Myro commands to control a robot, and have created a number of 2D graphics demos as well. As an example, the following programs demonstrate using the Graphics library in four Calico languages: Python, Scheme, F#, and Ruby. # Python Graphics Example import Graphics win = Graphics.Window("Hello") line = Line((0,0), (100,100)) line.draw(win) ;; Scheme Graphics Example (using "Graphics") (define win (Graphics.Window "Hello")) (define line (Graphics.Line (Graphics.Point 0 0) (Graphics.Point 100 100))) (line.draw win) // F# Graphics Example module MyModule let win = Graphics.Window("Hello") let line = new Graphics.Line(new Graphics.Point(0,0), new Graphics.Point(100,100)) line.draw(win) # Ruby Graphics Example win = Graphics::WindowClass.new("Hello") Figure 3: Examples created with Calico’s 2D Graphics library. line = Graphics::Line.new(Graphics::Point.new(0,0), Graphics::Point.new(100,100)) line.draw(win) and-drop Jigsaw language, Calico could also be used as an alternative to Scratch. Or with its Scheme support, it might serve as an alternative to NetLogo. The Graphics library is written once in standard C#, following some basic guidelines, and then compiled on any platform to a shared library. This shared library is then placed into a folder of the Calico Project, which makes it available to all of the supported languages. As can be seen from the above examples, the library provides a native interface for each language. It is important to note that there is no additional “glue” or “wrapper” code necessary to use a library. In addition, the library is not dependent upon the language that is using it, nor the operating system. In this manner, the compiled library can be used as-is with future languages or operating systems that have not yet been created. This will greatly facilitate the maintainability of the entire project as time goes on. The 2D Graphics library currently has support for basic drawing functionality, including shapes, turtle graphics, and image processing. In addition, the library also has a selection of “modes” for top-level windows to operate in. For example, “auto mode” will automatically update a window’s contents as soon as possible, but without overloading the system; “manual mode” leaves the updating of graphics completely under the user’s control; and “physics mode” imbues all shapes with physical properties such as mass and velocity under the influence of gravity. Physics mode allows for many interesting explorations into topics typically outside the scope of introductory computer science courses. For example, students can easily write their own version of the game “Angry Birds”, using nothing more than standard graphical shapes and turning on physics mode. The Myro robot library implements a well-tested API developed by the Institute for Personal Robots in Education (IPRE) [7]. This API has been ported by others to many languages, including C++, C, and Java. We are currently deploying Calico within a “robots first” CS1 setting. The 2D Graphics library is designed to support many different uses. For example, it can serve as a replacement for Zelle’s Python Tkinter-based graphics library [18]. Of course, since it is written as a generic Calico library, it is available to all of the Calico languages, not just Python. We would also like for it to eventually provide the functionality of Processing’s 2D graphical library [15]. Combined with the drag- To augment the Calico 2D Graphics library, we have also included in Calico a set of real world data. For example, we have included the regions of each US state in longitude/latitude format. Combining this with some supporting code for mapping longitude/latitude points to a window coordinate system allows students to easily create interesting visualizations. For example, one can plot the path of an active hurricane, or visualize by state the percentage of adult smokers (see Figure 3). The top image shows the path of Hurricane Irene plotted using a Calico function to map longitude and latitude to (x, y) window coordinates. The bottom image shows a visualization of the adult smoking population of various states. The darker the color of the state, the higher the percentage of smokers in the state. States are represented by polygons of longitude/latitude pairs that are drawn using Calico’s Polygon class. More generally, this library will make it easy for students to learn to manipulate and experiment with “big data” within many different contexts, using graphical visualizations as the primary tool. One of the main design goals of Calico is the separation of the pedagogical context from the programming language. This has the benefit of allowing one group of educators to focus their resources on developing interesting libraries and contexts, independently of other researchers working on language issues. Thus, the hope is to create many reusable components (languages, libraries, and contexts) that can be easily integrated and maintained within a single framework. Calico contexts may also incorporate the use of special hardware and other devices. Inexpensive sensors and effectors are increasingly available for use in the classroom. Hardware like Arduino microcontrollers [1], the Microsoft Kinect camera, and the iRobot Create robot are relatively inexpensive and allow students to write programs that interact with the real world. This physical presence can make students’ programs seem more relevant and engaging, as they are “authentic” problem domains. Our goal is to make cutting edge hardware accessible to all levels of the computing curriculum through Calico’s Devices library. For example, students using Calico in a creative computation class will be able to access the depth images provided by the Kinect, or to drive a Create mobile robot around using a simple, standard API. 3.1 An IDE for Interaction and Collaboration Learning a different programming language should not entail learning a completely different development environment. Too often, each language comes with its own extra baggage of IDE, libraries, and supporting framework. Educators should be free to focus the student’s attention on the ideas that matter, rather than on getting students up to speed in yet another new, unfamiliar environment. For example, the fact that Scheme uses functions and recursion as opposed to loops and mutable state is important; using the F5 key to run the program as opposed to some other key or menu option is not important. The Calico IDE has a fast, robust, extensible color syntax highlighter for all available languages, and allows switching between languages with a keystroke. Students can interactively enter commands in the currently selected language and see the results immediately. Any further improvements made to the IDE will automatically carry over to all of Calico’s programming languages and contexts. In addition to the shell and editor windows, Calico’s interface also has a third component, called Chat. The Chat window appears as a typical chatroom interface, and uses Extensible Messaging and Presence Protocol (XMPP) as the back-end protocol for communicating messages between the users’ computers and the server. The integrated chat interface allows students and teachers to communicate in a more modern medium. However, and perhaps more importantly, the XMPP connection can be used in ways other than as a chat interface. This provides a general mechanism for moving information between Calico clients. For example, we are currently exploring what we call “code blasting”. Using Calico, teachers will have the ability to blast code to students such that it shows up directly in their Calico editors. This will make it easy for them to immediately try out the examples being discussed in class. Likewise, students will be able to blast their assignments to their teachers, or perhaps blast code to each other. In addition, we have outlined plans to develop further support for interactive collaboration in Calico, so that two students could work together, even if they are in different locations. Finally, Calico is designed to incorporate the functionality of Personal Response Systems (often referred to as “clickers”), which can be used to provide interactivity in a classroom. Interactivity can be an effective way to enhance learning, even with larger class sizes. At this stage, we plan on implementing only a basic “quick poll” functionality. The instructor could initiate a question on the fly, perhaps with a multiple-choice answer selection, in order to gauge students’ comprehension of a particular topic. Students would each receive the quick poll via a pop-up dialog in Calico, where they would select one of the choices. Afterwards, the instructor could display a bar chart of the group’s responses, leaving individuals anonymous. The class could then either discuss the topic further, or move on to the next topic, depending on overall student understanding. 3.2 Technical Details Calico is designed to run identically on Linux, Macintosh, and Windows. In order to satisfy our cross-platform goal, we decided to implement the system on a virtual machine (VM). We considered two popular virtual machines: Java and .NET. Unfortunately, .NET only runs under Windows. However, an open source implementation of .NET exists, called Mono, which runs on all three target operating systems. Like Java, Mono includes both an object-oriented language/compiler and a virtual machine/runtime. However, although many languages can run on the Java VM, no common infrastructure exists, other than the VM itself, for each language implemented on the VM. This makes it difficult for different languages to share environments, data structures, objects, or functions. On the other hand, .NET and Mono have a framework for implementing languages called the Dynamic Language Runtime (DLR), and there already exist several languages written for the DLR, including Python and Ruby. The DLR contains many tools and technologies for implementing languages, along with support for making languages interoperable. Also, Java lacks a complete, robust, and official open source implementation. In contrast, .NET’s Common Language Infrastructure (CLI) has been clearly defined by Ecma standards #334 and #335 [5], and is protected by a promise from Microsoft not to sue [12]. The Mono virtual machine implements the Ecma standards. We have put a high value on Calico having a complete and open source “stack” of software layers, and for these reasons we decided to select the CLI as implemented by Mono as the basis of our system. Calico is designed to be easy to maintain and modify over time. The main Calico interface is written in IronPython, which has the advantage of allowing the interface to be easily altered without recompiling. For example, one can change Calico’s menus by simply editing a text file. Those changes are then reflected immediately on all platforms. We also selected Gtk as the graphical toolkit, as it is very robust and consistent across operating systems and has good documentation. The libraries are written in C# for speed. However, these libraries require only a single compilation on each operating system, after which they run identically on all platforms with any of the supported languages. 4. CONCLUSION [4] Dynamic Language Runtime. http://dlr.codeplex.com. Retrieved 9/2/2011. With Calico, one can pick the operating system, programming language, and context independently. Working within the Calico IDE, instructors and students can switch between different programming languages with ease while exploring a given context. Having the IDE and libraries be language-agnostic will make it easy to incorporate new, yet-to-be-invented languages into the system without having to reinvent all of the necessary supporting infrastructure, and without the need for adapting existing contexts to work with the new languages. [5] Ecma Standards. http://www.mono-project.com/ECMA. Retrieved 9/2/2011. It would be ideal if improvements to one educational IDE— DrRacket’s Scheme environment, say—could also benefit students using other languages. However, currently each such project is developed largely in isolation, and it is very difficult to apply advances in one environment to another. By providing an extensible, common framework spanning many programming languages and paradigms, enhancements to the environment or to a context benefit all of the languages, thereby creating a vibrant ecosystem for pedagogical development. As another example, computer science students typically study a variety of programming languages in a comparative manner in a junior-level programming languages course. Calico would be an excellent tool for side-by-side language comparison in such a course. But why wait until the junior year? Why not do this type of side-by-side comparison early in a computing curriculum? If switching languages were as easy as pressing a key, what pedagogical benefits would that offer the students? We hope to explore these questions through Calico. In summary, we hope that Calico will provide a long-term, robust framework that can be used to create and sustain a community of researchers, educators, and students working together. 5. ACKNOWLEDGMENTS An early version of this project was funded by NSF DUE grant #0920539 (Blank and O’Hara). Initial funding for the Myro project was provided for Blank and O’Hara by Microsoft Research. We would also like to thank Deepak Kumar for his support on this project. Finally, we would like to acknowledge the six institutions currently testing Calico: Bard College, Boston College, Bryn Mawr College, the Baldwin School, Macalester College, and Rowan University. 6. REFERENCES [1] Banzi, M. 2008. Getting Started with Arduino. O’Reilly Media / Make. December 2008. [2] Blank, D. 2006. Robots make computer science personal. Communications of the ACM 49, 12, 25-27. [3] Calico Project Home Page. http://calicoproject.org. Retrieved 9/2/2011. View publication stats [6] Guzdial, M. 2003. A media computation course for nonmajors. In Proceedings of the 8th Annual Conference on Innovation and Technology in Computer Science Education. ITiCSE ’03. ACM, New York, NY, 104-108. [7] Institute for Personal Robots in Education. http://roboteducation.org. Retrieved 9/2/2011. [8] Kelleher, C., Pausch, R., and Kiesler, S. 2007. Storytelling Alice motivates middle school girls to learn computer programming. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '07. ACM, New York, NY, 1455-1464. [9] Malan, D. and Leitner, H. 2007. Scratch for budding computer scientists. SIGCSE Bulletin (39) 1, 223-227. [10] Maloney, J., Resnick, M., Rusk, N., Silverman, B., and Eastmond, E. 2010. The Scratch programming language and environment. Transactions on Computing Education 10, 4, Article 16 (Nov. 2010). [11] Marceau, G., Fisler, K., and Krishnamurthi, S. 2011. Measuring the effectiveness of error messages designed for novice programmers. In Proceedings of the 42nd ACM Technical Symposium on Computer Science Education. SIGCSE ’11. ACM, New York, NY, 499-504. [12] Microsoft Community Promise. 2007. http://www.microsoft.com/interop/cp. Retrieved 5/17/2011. [13] NSF. 2003. Beyond LEGOs: Hardware, Software, and Curriculum for the Next Generation Robot Laboratory. NSF CCLI award #0231363. [14] NSF. 2009. Personal Robots for CS1: Next Steps for an Engaging Pedagogical Framework. NSF CCLI award #0920539. [15] Reas, C., Fry, B., and Maeda, J. 2007. Processing: A Programming Handbook for Visual Designers and Artists. MIT Press. [16] Resnick, M., Maloney, J., Monroy-Hernandez, A., Rusk, M., Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., and Kafai, Y. 2009. Scratch: programming for all. Communications of the ACM vol. 52 no. 11 (Nov. 2009), 60-67. [17] Summet, J., Kumar, D., O’Hara, K., Walker, D., Ni, L., Blank, D., and Balch, T. 2009. Personalizing CS1 with robots. In Proceedings of the 40th ACM Technical Symposium on Computer Science Education. SIGCSE ’09. ACM, New York, NY, 433-437. [18] Zelle, J. 2003. Python Programming: An Introduction to Computer Science. Franklin, Beedle, and Associates.