As CS educators, some of our greatest challenges revolve around the familiar phrase "CS is more than programming." Though simple and seemingly straightforward, this phrase encapsulates deep insights into the nature of CS, and the task of teaching CS at the K-12 levels while adhering to this phrase, is a complicated one, as was often demonstrated in this column. The complexity of this task is enhanced by the fact that, in practice, most introductory CS courses are designed as hands-on courses, in which programming plays a central role. Although this does not necessarily contradict the above phrase, it does necessitate a careful and constant effort to maintain a delicate balance, between teaching CS and teaching programming. That is, the balance between using programming in such courses as an effective tool for teaching CS ideas and concepts and making programming the learning goal of these courses. Since the general issue of the nature of CS has been addressed in this column from multiple angles and in multiple contexts, this article takes a concrete approach, using authentic, focused examples. The context of the discussion will be introductory CS courses for middle-school students. These students are perhaps young enough to encourage us to adopt a concrete approach, thus relying more heavily on programming; however, even a relatively concrete approach should not prevent us from maintaining the balance.

Consider the following scenario (its origin is real, although it was modified somewhat to fit into the limitations of this column): Jane (all names in this article are pseudonyms) is a middle-school CS teacher. She teaches an introductory CS course to 7th-graders, using Scratch. Jane is also somewhat familiar with Python. A colleague of Jane, Rachel, also teaches an introductory CS course to 7th-grade students, in another school, however, she is using Python. Rachel's course introduces strings, which are a basic entity in Python. Jane decides to include strings in her course, as well.

Janes' motivation to include strings in her course is very simple—other programming languages, such as Python, have them; we have them in Scratch since it offers three blocks—inroads1001_a.gif, inroads1001_b.gif, and inroads1001_c.gif—for manipulating strings, so why not? She teaches her students that a string is a sequence of letters, and that a length of a string is the number of its letters. Thus, the inroads1001_d.gif is 5, inroads1001_e.gif is the string hello world, and inroads1001_f.gif is r. In the next quiz she asks them what the result is of inroads1001_g.gif, inroads1001_h.gif, and inroads1001_i.gif. She finds these questions appropriate for assessing her students' ability to work with these blocks and to understand them.

We can discuss Jane's choices from several points of view. For example, we can argue that it is preferable to use a problem-based approach, starting with a problem that can be solved using strings and, hence, lends itself easily to introducing strings. We can also argue that it is preferable to assess students' understanding of strings through contextualized and situated questions. I chose to focus on Jane's motivation for including strings in her course, and I contend that this motivation is all about programming. She teaches strings because they are a familiar programming construct and they can be taught using Scratch. In fact, this motivation is consistent with Jane's other choices. In a traditional programming-oriented approach, programming constructs are introduced, explained, and then practiced, starting with simple unsituated questions, and moving gradually to using them in relatively complex program design. In contrast, a problem-based approach is consistent with the perspective of "CS is about problem solving," where programming constructs are a concrete manifestation of CS concepts (such as strings), introduced by the need to solve designated problems. Similarly, Jane's choice to assess students' understanding using syntax-focused questions, rather than questions that are situated in a problem-solving context, is consistent with a programming-oriented approach.

As opposed to this programming-oriented "why-not" motivation, a "why-yes" approach, leaning on explicit learning goals and objectives, can lead to deeper insights, which rise above the level of programming languages.

So why should we teach strings? Let us start with the generic question—why should we teach a specific programming construct or programming concept? In a course that aims at teaching CS rather than programming, there should always be one generic answer that justifies the inclusion of any programming concept—because it facilitates the teaching of a certain CS concept.

There are several CS concepts that can be taught using strings.

  1. Data type is a general CS concept that can be taught using a collection of data types, such as integer, character, Boolean, real, or string. In a language in which string is a primitive data type, strings, as a data type of a different flavor, can be used to enrich the data type vocabulary and the variety of primitive functions corresponding to different data types.
  2. Abstract data structure is an important central CS concept. Strings can be used for a gentle introduction to abstract data structures. To use strings, we should only know the characteristics of the data they hold (an ordered sequence of characters) and what we can do with these data (e.g., concatenate strings or append a character to a string). The use of strings is independent of their implementation (for example, through arrays).
  3. Basic concepts of the object-oriented paradigm: Certain languages allow the use of strings to gently expose students to basic object-oriented ideas. Python is a very good example of such a language, because of its versatile nature in terms of programming paradigms. Even when Python is used as a procedural language, strings can serve to plant the seeds of an entity (an object) that carries along with it attributes and methods for using them.
  4. String is also a CS concept, although its abstraction level is lower than those of the concepts in points 1–3 above. It is a specific data type, and a specific data structure. The programming-language construct of string is an implementation of this CS concept, just as the control structure if in Java, Python, or Scratch is an implementation (or even a translation) of the CS concept of selection.

When relying on a specific programming language to teach a certain concept, the first questions should be—is it possible to teach this concept using this language? Does it lend itself naturally to teaching this concept? Let us examine this for these four specific cases of data type, abstract data structure, basic object-oriented concepts, and string, when using strings in the context of Scratch.

Scratch is a bad choice for teaching the concept of data type, since it is not a typed language. Variables are defined by names only, and a variable can hold values of any kind. Similarly, an expression can combine different kinds of values. A naïve use of the features offered by the language will probably be typed, but such typing is no more than an interpretation of the programmer. As a result, some "anomalies" may occur, situations that are inconsistent with the concept of a data type, and specifically with the concept of string as a data type. For example, inroads1001_j.gif is a legal block in Scratch, and so are inroads1001_k.gif and inroads1001_l.gif. If var is set to the value 3.5, these three blocks will be evaluated to 3.5true, 7, and r, respectively. It is worth noting that the values of true and false are implicit and hidden in Scratch; there is hardly any way to explicitly and directly incorporate them, in their Boolean sense, into blocks. Therefore, most students will not even be able to interpret these results. Of course, there is no reason to expect that students will come up with such expressions, but they clearly demonstrate that Scratch does not support strings in any way. Obviously, strings cannot be taught in a language that does not support them, whether as a means for teaching the concept of data type or the more specific concept of string.

Similarly, since Scratch is a non-typed language, strings are a bad choice for demonstrating the concept of abstract data structure using Scratch, since the abstract data type of string can only hold character-typed data. However, it is possible to introduce the CS concept of abstract data structure using Scratch by means of lists, since lists can hold non-typed data. Finally, since Scratch is not an object-oriented language, but instead an event-driven one, obviously it cannot be used to introduce any basic object-oriented concept, whether through strings or in any other way [1].

With the aim of teaching CS rather than programming, we would advise Jane against teaching strings in an introductory course that uses Scratch. Specifically, we would advise Jane against using the specific blocks of inroads1001_m.gif, inroads1001_n.gif, and inroads1001_o.gif as means for manipulating strings. But should she avoid mentioning them at all? Jane, like many other CS teachers who use Scratch, has learned to appreciate the power of Scratch in motivating her students by enabling them to create colorful and attractive projects, which are also complex and challenging. Therefore, she encourages her students to design projects of their choice and requires them to submit a final project at the end of the course. She wishes to provide her students with as many tools as possible, thus enriching their vocabulary of Scratch. Does this contradict the principle of teaching a language construct only if it serves to fulfill a certain teaching objective of teaching a specific CS concept? Not necessarily.

If Jane is interested in enriching her students' vocabulary with specific Scratch blocks, she can still include them, if she finds a CS concept worth teaching that these blocks can support. The relations between concepts-to-teach and programming-language-constructs-to introduce can be formed either top-down or bottom-up. We can start from a certain teaching objective of teaching a certain CS concept and include the constructs that support its teaching, and we can start with certain programming-language constructs and match them with CS concepts. Either way, programming-language constructs will facilitate the teaching of CS concepts. Here are a few relevant examples (some of which are incorporated in [2,3]).

  1. As an event-driven language, Scratch easily lends itself to teach concepts that relate to agents, such as attributes of agents. Scratch agents (sprites) have a rich collection of built-in attributes, such as direction, costume, size, and location (x-coordinate and y-coordinate). The introduction of specific Scratch attributes or Scratch instructions relating to attributes can be linked to the concept of agents in an event-driven world. For example, the Scratch concept of pen can be introduced as another attribute of sprites, which can be in one of two states: up or down.
  2. Events in Scratch can also be initiated by the user, for example, pressing a key or clicking a certain sprite. Another channel of communication between the user and the inner world of Scratch is the mouse. Thus, instructions that involve the mouse can be presented as enabling the activation of this channel [2]. This channel is more complex than the channel of the keyboard, in which communication is achieved by pressing different keys, since a mouse can be moved and clicked. Because of this complexity, the mouse in Scratch also lends itself to the interesting issue of representation of abstract entities. Sprites are one way to represent entities in an abstract world. They can be used to represent different kinds of entities (e.g., a cat, a dancer, a button, or a moving obstacle). The entity of the mouse is also represented within this world, but in a different manner. It is represented visually by a pointer, but it is more than just a graphic symbol that can move on the stage, since it also has attributes (location, up/down). The use of the video camera in Scratch can also be introduced through these perspectives of channels of communication with the user, and representation of entities (in this case, the camera).
  3. Scratch is a special event-driven system, representing a world of agents that can move on a two-dimensional plane. Such agents need sensors to help them navigate on this plane. The perspective of sprites as entities that are equipped with sensors opens the door for different Scratch entities and instructions, such as those that involve touching the edge of the stage, another sprite, a certain color, or sensing the position or direction of other sprites. This perspective can also enhance the above-mentioned conceptual treatment of the mouse and the video camera, which relies heavily on sensing (e.g., sensing the motion of the camera [3] or the clicking of the mouse [2]).
  4. The challenging concept of black-box abstraction or procedural encapsulation can be gently introduced in Scratch using built-in blocks, before moving on to the more difficult topic of user-defined blocks. For example, in Scratch there is a designated block for calculating the distance between a sprite and other entities (other sprites or the mouse pointer). This is a useful block but, in a sense, it is redundant since this distance can be calculated using the blocks that sense the position of another sprite or the mouse together with built-in mathematical operators. However, its existence allows us to ignore the details of this calculation and use it as a black box. Thus, introducing this block can serve to expose students to the idea of procedural encapsulation [2].
  5. The general concept of simulation can be addressed and demonstrated in Scratch in various ways through the perspective of simulating a three-dimensional world by means of a two-dimensional one. This perspective provides a natural opportunity to introduce layers in Scratch. Layers can also be connected to the concept of agents' attributes.

If Jane emphasizes the theme of "CS is about problem solving" and follows a problem-based approach, she can also enhance her students' vocabulary by posing them a rich variety of problems during the course, so that different instructions will prove to be useful for implementing specific steps of solutions. In such cases, instructions are introduced at the right time, as needed, and justified by context. For example, if a problem requires a sprite to make an announcement that combines pre-defined words with values that are only evaluated during execution (see Figure 1), this can be achieved by joining the two components, thus offering an opportunity to introduce the inroads1001_m.gif block as a way to translate this into Scratch [2]. Although this pedagogical strategy does not result in a match of a programming-language construct and a CS concept, it does serve to demonstrate the process of CS problem solving, which can be viewed as an underlying general idea of CS.

Incorporating such strategies into an introductory CS course, even at young ages, is consistent with the widely used approach of spiral teaching, which was often discussed in this column [4]. CS concepts and ideas, even challenging ones, are to be introduced from the very first stages of CS education, at a level and in a manner that are appropriate for the students' cognitive development phase, thus fostering their meaningful learning. Moreover, this approach can be implemented within the standard time frame of the course. It is mostly about making explicit connections, generalizing, and recognizing opportunities.


1. Armoni, M. On teaching problem-solving paradigms in K-12 education. ACM Inroads, 8,4 (2017), 30–32.

2. Armoni, M., and Ben-Ari, M. Computer Science Concepts in Scratch (2013); Accessed 2018 December 2.

3. Armoni, M., and Ben-Ari, M. Computer Science Concepts in Scratch (Supplement for Scratch 2.0) (2013); Accessed 2018 December 2.

4. Bruner, J. S. The Process of Education. (1960) (Cambridge, MA, Harvard University Press,1960).


Michal Armoni
Department of Science Teaching
Weizmann Institute of Science,
Rehovot, 76100, Israel
[email protected]


F1Figure 1. Announcing a compound sentence

Copyright held by author.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2019 ACM, Inc.

Contents available in PDF
View Full Citation and Bibliometrics in the ACM DL.


There are no comments at this time.


To comment you must create or log in with your ACM account.