Explicative Programming

With substantial confusion left regarding the meaning, as well as the purpose, of Computational Thinking (CT), 15 years after Jeannette Wing’s seminal Communications Viewpoint,⁷ two different schools of computational thought have emerged. In the more prominent school of thought—let’s call it vocational education—the boundary between programming and CT is somewhat blurry. No doubt, the understanding of coding constructs is an essential part of CT education. However, if teaching and assessing CT is largely based on concepts such as loops, sequences, and conditional statements, then how is this fundamentally different from programming? The arguments for and against this school of thought are numerous but the most ubiquitous ones, at least in the U.S., appear to be career oriented and are grounded in predominantly economic justifications. Unfortunately, in the vocational school of computational thought the benefits of CT toward disciplines other than computer science are at best collateral.

Enter the second, less developed, school of computational thought focusing on general education. We will call this “Explicative Programming.” In this school, programming may not be in the foreground, but it becomes an interdisciplinary instrument of thought to truly understand powerful ideas in typical K-12 disciplines such as STEM, art, language, and music. In the Explicative Programming school of computational thought, CT is about thinking with the computer. This idea is not new. In fact, it predates the Wing vision and can be traced back to Seymour Papert. Papert initially employed the term “Computational Thinking”³ to refer to a relation between problem disciplines and what he referred to as an explicative practice of programming.

Explicative Programming facilitates CT thinking by establishing a bidirectional connection between typical K-12 disciplines and computer science (see Figure 1). The motivational aspects of this type of connection have long been recognized by the educational reformer Dewey as “instrumental motivation.”² Instrumental motivation is an indirect kind of motivation—just like learning a few words of French may enable you to order food at a restaurant in France. In this example, instrumental motivation suggests you are mostly interested in eating food, not learning the French language. Similarly, with Explicative Programming, instrumental motivation may foster interest in either “learning to program,” or “programming to learn” or both (see Figure 1).

Figure 1. Explicative Programming connects traditional K-12 disciplines with programming through bridging constructs.

• Learning to program. Disciplines such as STEM, music, art, and languages, suggesting applications such as games, simulations, robots, stories, and animations, can serve as engaging contexts to develop programming skills.
• Programming to learn. Programming can serve as a dialectic to support understanding and expose misconceptions in disciplines such as STEM, music, art, and languages through hands-on inquiry processes.

It should be noted that while in theory the ideas of the vocational and explicative schools of thought could be combined, we have observed that instruction leans toward vocational education because of practical reasons. While the vision of Explicative Programming to make CT relevant to K-12 schools is highly appealing, it is incredibly challenging to implement the bidirectional connections (Figure 1, red arrows). Because of this difficulty, Explicative Programming has not yet reached systemic impact in schools. Establishing a bridge between traditional K-12 disciplines and computer science requires not only a solid understanding of both disciplines but, even more importantly, the understanding of how to meaningfully connect them. Unfortunately, teachers are quite unlikely to have relevant experience. The daunting gap between K-12 disciplines and programming needs to be connected through carefully designed bridging constructs (see Figure 1) serving as stepping stones between disciplines and programming (Figure 1, green box and arrows). Two examples employing CT patterns¹ as bridging constructs are described here: these projects are programmed with the AgentCubes⁴ Computational Thinking Tool.

Back to Top

Example 1. Collision pattern to create a virus simulation.

The virus simulation is an example of an Explicative Programming activity that can fit within the curriculum of a Life Science classroom. To program the virus simulation, students must program a healthy person, with some percent chance, becoming sick when coming into contact with a sick person. The bottom of Figure 2 depicts an implementation of this collision computational thinking pattern as an IF/THEN expression with a percent-chance condition of 70%. The ability to count populations of characters, allows students to experiment by changing the percent chance of becoming sick, as well as rate of death and recovery, to determine, for example, the effect different disease susceptibilities have on the population over time. This in turn enables discovery. For instance, students often try to create a deadly disease by making the death rate something close to 100%. What they find is that this, counterintuitively, leads to less total death among the population, as many of us now know. This discovery has been witnessed from middle school to graduate school classrooms⁵ and enrichment programs such as the June 2020 Black Girls Code Epidemiology Virtual Workshop (https://bit.ly/BGCVirusSim).

Figure 2. The collision-change pattern implementation (bottom middle) of the epidemiology simulation in AgentCubes with population data depicted. The rule shown reads: “If I am next to one or more sick characters, and currently healthy, I become sick with a 70% chance.”

---

Enter the second, less developed, school of computational thought focusing on general education.

---

Back to Top

Example 2. Probabilistic generation pattern to create a Frogger game.

Game design⁵ provides ample opportunities for Explicative Programming, for example, enabling bridging constructs whereby implementation supports Computational Math Thinking. For instance, in a Frogger-like game design activity, students need to program cars driving on a busy multilane highway as an obstacle for a keyboard-controlled frog to cross. To make the game easier, but also not too simple, necessitates the correct numbers and distributions of cars on these roads. Employing the probabilistic generation pattern, students program the tunnels on the left generating cars with a certain frequency and probability. If a low frequency (every 0.6 seconds) but high probability (100%) is used, then the result will be a wave of simultaneous cars, which looks unnatural (Figure 3, left) and makes the game play too predictable. Experimenting with the construct and selecting a high frequency (every 0.06 seconds) but low probability (10%) results in much more compelling game play (see Figure 3, right) bridging math with game design.

Figure 3. Left: Generating new cars with low frequency and high probability (100%); Right: High frequency and low probability.

Our experience from teaching Scalable Game Design⁵ to students and teachers, all over the world suggests three key principles of bridging constructs to effectively facilitate Explicative Programming.

Back to Top

Bridging Constructs Should:

1. Foster creativity by serving as highly reusable concrete abstractions. Constructs should enable students to create personally meaningful artifacts, such as games, by breaking down existing games or their own game design ideas into common design patterns they have learned to program. Just as architects are not thinking about houses in terms of nails or bricks, these patterns are at a much higher level of design abstraction than programming constructs such as IF or LOOP statements. We found Computational Thinking Patterns to be highly effective to serve as bridging constructs to build games and STEM simulations.¹ Computational Thinking Patterns operate at the level of phenomena describing interactions of two or more objects such as generation, collision, transport, absorption (see left), hill climbing, and diffusion. Discipline-oriented CT patterns, such as the probabilistic generate pattern employed in Example 2, are useful to engage in Computational Math Thinking, Computational Music Thinking,⁶ and Computational Art Thinking through Explicative Programming. Programming these patterns includes the need to understand affordances of CT tools. Not all block-based, or text-based, programming languages are alike. What may be elegant and simple with one tool may be convoluted and nearly impossible with another one (http://tiny.cc/affordances).
2. Enable dialectic. Dialectic is a reasoning process explaining powerful ideas by exposing misconceptions through inquiry. To make Explicative Programming dialectical the “learning to program,” and just as importantly, the “programming to learn” red arrows of Figure 1 need to be supported. Explicative Programming is not just integrated computer science education. For example, say in a science course, the teacher wants students to understand planetary motion. Students create an animation of an earth sprite moving around the sun. Earth is programmed, much like the “turtle” in Logo, using a loop to iteratively make the earth move forward some pixels and then turn right some degrees. This results in a nice animation of the earth rotating around the sun. However, it does not qualify as explicative any more than the creation of a static diorama made out of paper, wire, and tape. This activity does not engage students in a dialectical process challenging misconceptions or extending their understanding of planetary motion. In contrast, the dialectic in Example 1 is about uncovering surprising phenomena of spreading viruses, and in Example 2, the dialectic is about experimenting with compound probabilities resulting from tuning frequency and probability of multiple tunnels generating multiple cars.
3. Facilitate instrumental motivation enabling students to create meaningful artifacts. Instrumental motivation,² as explained previously, helps to connect disciplines with programming. Students may not be intrinsically interested in programming but may want to build personally meaningful artifacts such as simulations (Example 1), games (Example 2), animations, stories, and robots. With a discipline-oriented CT pattern, such as the probabilistic generate pattern employed to create Frogger in Example 2, instrumental motivation may result in the interest to understand math/probability because its mastery helps to create a more playable game. This is in strong contrast to traditional math learning in schools where mastery of the subject is often perceived by students as hardwired aptitude and not as an enabling instrument. Unlike students, teachers may not intrinsically care about game design, but once they see students become highly engaged to learn programming through game design teachers will likely appreciate game design as an effective pedagogic method.

---

The daunting gap between K-12 disciplines and programming needs to be connected through carefully designed bridging constructs.

---

Back to Top

Conclusion

If Computational Thinking is to be not just another item in a crowded curriculum that must be taught, but instead wants to become truly relevant to public schools, it has to radically change its perspective toward interdisciplinary education. How can programming support the effective teaching of STEM, art, music and languages? Perhaps the generic notion of CT needs to be replaced with discipline-oriented versions such as Computational Math Thinking, Computational Music Thinking, and Computational Art Thinking. By providing educators and students constructs to bridge the vast gap between typical K-12 disciplines and programming, Explicative Programming, evolving Seymour Papert’s original conceptualization of Computational Thinking, is doing just that.