Programming is such a powerful tool that as early as the 1960s scholars such as C.P. Snow and Peter Naur were worried about its potential negative impacts on society.a They called for everyone to learn to program in order to democratize access and to inform citizens about how computational processes worked. At the same time, Alan Perlis argued for teaching programming to all university students because of the disciplinary benefits. He saw that computing gave us a new way to understand in many disciplines. His words have proved to be prescient.
Historians, scientists, humanities scholars, mathematicians, and artists today use programming to advance the goals of their own disciplines. They are using programming for their own agendas, for problems other than professional software development. These professionals are likely using a broad range of tools, such as Excel, MATLAB, Python, R, and JavaScript. Domain-specific languages (DSLs) are a class of languages designed explicitly for domain experts to use in solving problems for which programming is a useful tool.
We aim to bring domain-specific programming into classrooms. Only approximately 5% of U.S. high school students take a course in computer science.b If we were to integrate programming into a broad range of classrooms, especially in subjects other than computer science, we might help to democratize access to programming and give all students the opportunity to learn programming for all the reasons that Snow, Naur, and Perlis raised, not for the purpose of creating more software developers.
We aim to bring domain-specific programming into classrooms.
DSLs are designed for solving problems in the domain. Students do not know the domain nor programming. Teachers outside of computing have domain expertise, but typically no programming experience. They are also gatekeepers. Teachers make the decisions for what to bring into their classroom and what will help their students the most.
Our approach is to make programming more accessible by making new languages that are even easier to use than DSLs. We work with social studies and mathematics teachers who do not currently use any form of programming in their classes. They have no interest in learning programming for its own sake. However, they want to incorporate activities that require students to program, as a way to learn more within their discipline. We design programming languages with and for these teachers. We create Task-Specific Programming (TSP) languages since they are made just for the teacher’s tasks. We call these teaspoon languages—we are adding a teaspoon of programming into other-than-CS subjects.
The teaspoon languages we have built to date have three defining characteristics:
- They can be used by students for a task that is useful to a teacher. Integrating into formal, mandatory schooling through teachers is the best way to get broad access and participation.
- They are programming languages, that is, a notation for defining a computational process.
- They can be learned within 10 minutes, so students can learn and use them within a single class session. A larger language requires more time to learn. To be worthwhile, that cost must be amortized across many sessions to be worthwhile. That is a big investment for a teacher who has not used programming previously.
Participatory Design of Teaspoon Languages
We started building teaspoon languages in collaboration with Tammy Shreiner, a history professor at Grand Valley State University. All U.S. states require social studies classes (including history) to teach data literacy, but not all teachers include it in their classes. We have brought a variety of data visualization tools to her course for teachers, Data Literacy for Social Studies. We have her students try them out and tell us what would fit best into their courses. Some of these tools required programming and others did not.
Some teachers valued programming for specifying data visualizations. With a drag-and-drop tool, it is not always easy to understand how you got to a particular visualization or how to change it. Social studies teachers often want to generate two visualizations for comparison, so efficiently specifying multiple visualizations is important to them. Teachers appreciated the declarative programming language in one of the tools we showed them, Vega-Lite, for its simplicity, clarity, and parsimony.
Figure 1 is a screenshot of a teaspoon language for data visualizations we have developed. In Data Visualization for Learning (DV4L), the two visualizations appear on the right. The code for defining the visualizations is in the center, inspired by Vega-Lite. Menus for controlling the visualization are on the left. These are linked. Changing the code changes both the graph and the settings in the menus. Changing the menus changes the graph and the code. There is a “Driving Question” above the visualizations on the right. Social studies teachers told us that students need to be reminded why they are playing with visualizations, so we built the driving question into the interface.
We use participatory design methods to create teaspoon languages. We put existing programming languages in front of teachers as design probes, guide their use of the tools, then ask them to reflect on what worked and what did not. We typically work closely with a co-designer, like Shreiner, who is both a teacher and a domain expert. The teachers who participate in our sessions are design informants. They inform us about their values, like the importance of having two visualizations at once, having the driving question be visible at all times, and of what they value in a code notation.
Pixel Equations (screenshot in Figure 2) is a teaspoon language for mathematics classes. We developed Pixel Equations for a collaboration between a Detroit Public School and robotics faculty at the University of Michigan. The Detroit school wanted to develop an Engineering course for their 11th-grade students (approximately 16 years old) where they would be asked to visualize data from a sensor. We interviewed undergraduates who had solved the same problem in their robotics course to identify what was difficult about the task. We also worked with mathematics teachers and mathematics education researchers to identify learning objectives in the task.
Pixel Equations is used to define image filters. We identified three learning objectives that were particularly difficult for the undergraduates and were important to the teachers.
- Equations that define parts of a plane (for example, x < 0) can be used to define regions of a picture to which a filter might be applied.
- We can use mathematics to define colors (for example, to define the amount of red, green, and blue in a color).
- Pixel colors can be queried (for example, increase the red wherever blue > 120) to specify pixels to change.
In Pixel Equations, regions are specified in the first column. Wherever the logical expression is true, the right side color specification is applied. The three columns to the right specify the red, green, and blue components for the pixel color. Expressions can use the old value of the color to define a new value (for example, 2 * red to double the red in a color).
A Pixel Equations program is a program without for loops or explicit if statements. It is clearly limited in scope and only good for one task (defining image filters). Nonetheless, it is a motivating task that addresses learning objectives relevant to engineering, mathematics, and art classes.
Building In Support for Multilingual Students
Figure 2 demonstrates one of the features we have been exploring in teaspoon languages. Pixel Equations supports the use of red, green, and blue for specifying color components, and also rojo, verde, and azul. Since we are defining entirely new programming languages, we do not have to be constrained in our choice of words. We do not have to maintain the hegemony of the English language in programming.
Wherever we can, we support non-English choices for keywords. A different teaspoon language, for defining chatbots, supports the mapping of keywords to many languages. We currently include English-based, Spanish-based, and Spanglish-based chatbot languages. We built our Charla-bot teaspoon language based on an explicit challenge from Sara Vogel, whose work on translanguaging in bilingual CS classes inspired us. We asked her to review an earlier version of the chatbot tool and asked, “Would you like this with Spanish keywords?” She responded, “Could you make it so that the students could pick their own keywords?”
Research Challenge #1: Programming is Interpretation
While our teaspoon languages are understandable and usable in under 10 minutes, the users are still programming. Whenever you are programming, you are specifying a process for a computational agent who does not understand the human world. Mismatches occur between desired intent and actual execution. Teaspoon language programmers still must learn how to debug.
Our work with teaspoon languages gives us new insights about what students need to learn to develop “computational thinking.” Beginning programmers must understand programming is not like a word-processor or presentation tool. The input (program) does not look like the output (execution). There is a process of interpretation or translation by the computer on the input to get to the output. Many users of smartphone or Web apps have never experienced an explicit process of interpretation of a notation. We are working to help teaspoon language users to navigate programming bugs for the first time.
Research Challenge #2: Adoption
While our teaspoon languages score highly with teachers on measures of usability and usefulness, they have not been widely adopted. There are many barriers to adopting programming for the first time. Not many history teachers have computers for all their students. New social studies teachers might have learned about building data visualizations, but they are unlikely to push their more senior colleagues toward new methods in their first years. When pressed for time, teachers often jettison the technology first.
We are conducting studies to understand the factors that influence adoption. Today, we work closely with a handful of adopting teachers, to understand what works for them and how we can better facilitate their use. These teachers use teaspoon languages because they believe they help students learn in their subject.
An Interdisciplinary Research Direction to Broaden Participation and Access
Teaspoon languages are a new target for programming language design, developed with HCI design processes with non-programmers to achieve education goals. Using teaspoon languages is programming, in the way that Snow, Naur, and Perlis meant it. Teaspoon languages are about democratizing access to the activity, about increasing understanding of computational processes, and about applying programming to advancing disciplinary goals. Maybe students will get interested and want to do more programming, but our goal is to meet the teacher’s disciplinary needs, not convert students to computing.
We see teaspoon languages as a strategy for broadening participation in programming. Few U.S. high school students take a computer science class, but 100% of these students take history, mathematics, and science. Helping to integrate programming across the curriculum gives all students the opportunity to discover programming and how it can be useful to them in their lives and careers, even if they never become part of the computing field.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment