Conceptualizing Flexibility in Programming-Based Mathematical Problem-Solving

Abstract

Computational thinking (CT) has received much attention in mathematics education in recent years, and researchers have begun to experiment with the integration of CT into mathematics education to promote students’ CT and mathematical thinking (MT) development. However, there is a lack of empirical evidence and new theoretical perspectives on the mechanisms of interaction between CT and MT. To address this research gap, this study analyses the participants’ thinking processes in solving programming-based mathematical problems from a flexibility perspective, focusing on the interplay between computational and mathematical thinking, that is, how CT and MT work together to influence and determine the problem-solver’s choice of solution strategy. Using data collected from a large design-based study, we summarise two types of flexibility and six subtypes of flexibility demonstrated by participants in the programming-based mathematical problem-solving process using thematic analysis. These different types of flexibility provide researchers and mathematics educators with new theoretical perspectives to examine the interplay of CT and MT. Findings will also contribute toward student learning characteristics in programming-based mathematical problem-solving to sketch the big picture of how CT and MT emerge in complementary or mismatching ways.

Keywords

mathematical thinking computational thinking programming flexibility interplay problem solving mathematics education

Introduction

Computational thinking (CT) is regarded as a fundamental skill required in daily life and a kind of analytical thinking that shares common characteristics with mathematical thinking (MT), engineering design, and scientific inquiry in many ways (Wing, 2006, 2011). Thus, research has focused on investigating ways to integrate CT into K-12 educational contexts (e.g., Feldhausen et al., 2018; Jocius et al., 2021). One kind of such integration that has gained high attention is incorporating CT into mathematics teaching and learning through programming education (e.g., Kaufmann & Stenseth, 2021; Rodríguez-Martínez et al., 2020; Sung et al., 2017). Amid the promise and potential for a “computationally enhanced mathematics education” (Ng & Cui, 2021), several conceptual and pedagogical issues should be resolved for better understanding how CT can be effectively synergised in mathematical disciplinary instruction. Amongst these, a key challenge is to understand how CT and MT work together to influence students’ strategies and competence when engaging in mathematical problem-solving in computational contexts. Previous studies have identified discrepancies between CT and MT, which make mathematical problem-solving in computational contexts challenging for students (Cui & Ng, 2021; Ng et al., 2021). Also, the integration of CT into mathematics education requires reconceptualization and reorientation of task and pedagogical design (and their sequence), and addressing these aspects of teaching and learning presupposes that we can clearly understand the roles and connections between CT and MT. Therefore, there remains more effort in addressing the complex relationship between CT and MT to integrate CT meaningfully into mathematics education.

In recent years, researchers have explored a variety of CT-based mathematics instruction and programming tools, in which students construct programming artefacts flexibly while developing problem-solving competence and engaging with mathematical concepts in various domains (see a review in Ye et al., 2023). While the breadth of research has advanced the empirical bases for the design of CT-based mathematics instruction and what student learning entails under such an environment, very little is currently known about the processes of how CT and MT specifically work together and co-emerge in this context. Meanwhile, noting the diversity of solution strategies in programming-based mathematical problem-solving, we propose that research on flexibility in mathematical problem-solving may provide possible directions for our attempts to explore the interplay between CT and MT. Flexibility refers to “the ability to change according to particular circumstances” (Star & Seifert, 2006, 281), which relies on the problem solver’s understanding of the problem situation and relevant knowledge for working on the problem solutions. Therefore, if the problem context is extended to programming-based mathematical problems, the problem solvers would require knowledge of programming and mathematics, as well as to adapt this knowledge according to the programming environment used for the problem context. We consider this adaptability central to “flexibility in programming-based mathematical problem-solving”.

In this study, we are interested in delving into the interplay between CT and MT in programming-based mathematical problem-solving from the perspective of flexibility. Having conducted various empirical studies (Cui & Ng, 2021; Ng et al., 2021; Ng & Cui, 2021; Weng, Cui, et al., 2022; Weng, Ng, et al., 2022) and a systematic review (Ye et al., 2023) which examined student learning in CT-based mathematics instruction, our aim for this paper is to contribute toward conceptualizing the kinds of flexibility involved in the problem-solving processes when participants engaged in solving the designed tasks from our previous studies. We adopt the method of thematic analysis to further interpret the connection involved between participants’ CT and MT in the programming solutions and characterise the kinds of flexibility exhibited in programming-based mathematical problem-solving. Such an analysis has the potential for understanding the mutual cognitive development in CT and MT, including how mathematical concepts are integrated into the problem-solving and programming processes, and the role of CT in such processes. Thus, the study is guided by the research question: How do problem solvers integrate CT and MT in their solutions to mathematical problems expressed in programming contexts? Specifically, what types of flexibility are exhibited during programming-based mathematical problem-solving?

Theoretical Background

Computational Thinking and Mathematical Thinking

In this study, we adopt Wing’s (2011) definition of CT as “the thought processes involved in formulating problems and their solutions so that the solutions are represented in a form that can be effectively carried out by an information-processing agent” (p. 20). Moreover, taking Burton (1984), we define MT “[not as] thinking about the subject matter of mathematics but a style of thinking that is a function of particular operations, processes, and dynamics recognizably mathematical” (p. 35). In other words, both CT and MT refer to the cognitive structures that govern an individual’s programming and mathematical activities respectively, as well as the anticipation of the results of those activities (Piaget & Inhelder, 1968; Von Glasersfeld, 1995; Wing, 2006). Although CT and MT seem to be two kinds of thinking from different disciplines, CT is thought to share similarities with MT in terms of problem-solving (Wing, 2008). For example, Barr and Stephenson (2011) identified several core CT concepts and capabilities (e.g., data collection, problem decomposition, abstraction, automation) embedded in activities across computer science and mathematics. Of significance is the CT feature of problem decomposition, which is also reflected in mathematical activities, such as applying order of operations in mathematical expressions. In addition, the use of conditionals is commonly found in both programming and mathematical activities, where CT is manifested by using “a set of decisions, actions, statements executed based on numerical, algebraic or geometric properties” (Ye et al., 2023: 14).

Recent research has also attempted to determine the empirical connections between CT and MT, with some reckoning that CT and MT are mutually supportive or have overlapping features (Dickes et al., 2020; Ng & Cui, 2021; Pei et al., 2018; Sinclair & Patterson, 2018). In Ng and Cui’s (2021) study, mathematical exploration was shown to serve as a site for students to engage in CT in meaningful ways. They reported on students’ development in CT concepts (e.g., iterations/loops, variables, conditions, operators, and sequences) and CT practices (e.g., abstraction, modeling, algorithmic thinking, testing and debugging) when programming in Scratch to solve mathematical problems, such as determining the balance of saving over time, and making a prime number detector. Another group of researchers have described students’ mathematical development through engagement in CT (Echeverria et al., 2019; Sáez-López et al., 2019; Sung et al., 2017). For example, Sáez-López et al. (2019) identified statistically significant improvements in students’ understanding of whole numbers and coordinate values upon working with programming robotics. On the other hand, the presence of CT and MT may occur in mismatching ways. As Rich et al. (2018) point out, mathematics focuses on students’ flexible arithmetic operations and arithmetic strategies, while CT focuses on sequence so that the computer can recognize and execute. Therefore, the relationship between CT and MT is not always complementary, and both commonalities and inconsistencies are observed.

While these studies point to an inter-relationship between CT and MT (e.g., CT supports MT, or vice versa, the two are constraining), the conclusions are relatively broad and lack a more specific perspective on how such facilitative or hindering relationships of CT and MT arise and develop. In this study, we attempt to collect more evidence to capture the presence or expression of CT and MT in a clear way, and how they affect students’ thinking processes when engaging in programming-based mathematical problem-solving.

Flexibility in Problem Solving

Flexibility is considered a key competency in problem solving (Star et al., 2015); however, there remains some variability in its definition in mathematics education research. Meanwhile, adaptivity is often discussed alongside flexibility by researchers. The two are sometimes considered synonymous but are also sometimes used by researchers to strictly distinguish between the different competencies exhibited in problem solving. For example, ‘flexibility’ emphasizes the ability to switch (smoothly) between different strategies, while ‘adaptivity’ refers to the ability that choose a strategy appropriately (Selter, 2009; Verschaffel et al., 2009). Finally, some scholars define flexibility as encompassing both; that is, flexibility refers to learners’ knowledge of multiple solution strategies and the capacity to choose the most suitable strategy in a given mathematical problem-solving context (Rittle-Johnson & Star, 2007; Star et al., 2022; Star & Seifert, 2006).

Even if research focusing on flexibility has been conducted extensively in different domains of mathematics, there has been little research on interdisciplinary flexibility, or how flexibility manifests across different subject domains. In this study, we adopt flexibility as “knowledge of multiple strategies and the ability to select the most appropriate strategy for a given problem and problem-solving circumstances” (Star et al., 2022: 2) and extend the definition to observe how flexibility is demonstrated through our designed programming-based mathematical problems. This investigation has the potential to refine our understanding of how problem solvers make connections between computational and mathematical concepts, as well as how CT and MT co-develop when engaging in programming-based mathematical problem-solving. Particularly, we pay attention to the tasks in which problem solvers are situated to translate between mathematical and programming language, and to integrate mathematical and computational concepts to demonstrate meaningful connections of CT and MT. When analysing these tasks, we recognise that programming itself is a tool-mediated activity; therefore, the instrumentation of different programming tools could vary, and this necessitates different kinds of CT-MT translations and connections to occur. For this reason, we choose to address one specific programming language, Scratch, and the kinds of flexibility demonstrated in programming-based mathematical problem-solving is regarded as a Scratch-mediated activity.

Method

Participants and Context

This study is part of a large design-based research (DBR), with three iterative cycles of design-implementation-analysis-redesign, which addressed the research objectives of (1) designing a series of tasks for supporting the practice of computationally enhanced mathematical problem-solving in school mathematics classrooms, and of (2) studying student learning trajectories in terms of developing their CT, MT, and problem-solving competence when engaging in the designed tasks. The participants in this study were recruited from two kinds of workshops. The first was a set of student workshops, taking place in the form of extra-curricular activities led by the researchers (more in the next section), which recruited seventh to ninth grade (age 12–15) students (n = 95) from three secondary schools in Hong Kong. These workshops consisted of 10–12 contact hours, specifically, over five 2-h sessions at School A, six 2-h sessions at School B, and five 2-h sessions at School C.

The second set of workshops was intended for in-service mathematics teachers, who participated in a series of five sessions (of 2 hours each) of online professional development in Scratch programming over five weeks. Eight in-service mathematics teachers were recruited from different secondary schools to participate in the workshop series. The teachers had a range of 1–5 years of teaching experience with no prior experience with Scratch programming and expressed a keen interest in learning programming-based mathematical activities as part of their professional development. As the purpose of this study was to explore the flexibility of participants’ strategies while solving programming-based mathematical problems, we included both groups of participants (students and in-service mathematics teachers) to appropriate our response to the RQs, since we were more interested in the variety of programming solutions as opposed to the participants’ prior knowledge and experience in this study.

Task Design and Data Collection

The workshop series each began with an introductory game design to familiarize the participants with basic Scratch programming, followed by several programming-based mathematical problem-solving tasks related to four mathematical domains: number, algebra, geometry and data handling. A total of 19 tasks were studied in response to the research question posed, from which 14 of them were taken from the student workshops, and 5 were taken from the teacher workshop. In Table 1, we illustrate our task design of one sample task from each of the four domains. As can be seen, the designed tasks were presented as programming-based mathematical problems, and they exemplified open-ended problems with no fixed coding strategy.

Table 1.

Sample Task.

Domain	Name of Task	Task Description
Number	Prime number tester	Write a scratch program that can be used to verify whether an input number is prime or not.
Algebra	Concert Hall seat problem	Tom is having a concert and wants to know how many seats are available in the concert hall. There are 18 seats in the first row and 25 rows in total. In addition, there is one more seat in the row behind each row. Based on what Tom has observed so far, how would you use scratch programming to help him calculate the number of seats in the concert hall?
Geometry	Drawing polygons	Use the pen function to write a program that can draw different regular polygons of different sizes.
Data handling	Dart problem	Write a program to simulate a dart game which can automatically throw a ball onto the dartboard and record all the results.

In the student workshops, some time was set aside for whole-class discussions aimed at giving instructions, introducing pertinent CT and/or mathematical knowledge, and reviewing the programming activities with the class, with the majority of time spent on students’ problem-solving. The whole-class interactions as well as the behaviour of the researchers and students were recorded by the digital camera in the classroom. While the students were engaged in programming work, the research team walked around the room to interact with the students and encouraged them to explain their working solutions. During this time, voice-recording and field notes were taken, and screen capturing was turned on, which captured the students’ facial expressions.

In the context of the teacher workshops which were conducted with a smaller number of participants via Zoom, task-based interviews and screen recording were the main data collection approaches. The teachers worked in pairs to solve the posed programming-based mathematical problems. At this time, the researcher observed and conducted task-based interviews to gain insights into their thinking processes. Time and support were given when needed as the teacher pairs experienced challenges. In summary, data collected for this study include video recording, voice recording, field notes, screen capturing, and programming artefacts.

Data Analysis

We adopt the method of thematic analysis to identify, analyse and report patterns of data (Braun & Clarke, 2006); thematic analysis is suitable for this study for it identifies not only similarities, but also differences, as well as yielding unforeseen insights and summarizing key features of a large data set (Nowell et al., 2017). Specifically, we use thematic analysis to identify how participants demonstrated flexibility in their solutions in the designed tasks. Taking the participants’ programming solutions as the primary source of analysis and the rest of the data set as source for triangulation, we conducted latent thematic analysis rather than semantic analysis to go “beyond the semantic content of the data”, and to “identify or examine the underlying ideas, assumptions, and conceptualizations – and ideologies – that are theorized as shaping or informing the semantic content of the data” (Braun & Clarke, 2006: 84); in doing so, we develop themes from an interpretive effort, upon which the resulting analysis is not just descriptive, but is already theorized. Our analysis was based on the following six steps of performing thematic analysis as outlined by Braun and Clarke (2006).

In Phase 1 (Familiarizing with data), all authors familiarize themselves with the individual tasks and the participants’ solution strategies by watching video-recordings, sorting out participants’ programming artefacts and field notes, etc. Then, we looked at the macroscopic features of each programming solution, focusing on the patterns between mathematical and programming expressions in Phase 2 (Generating initial codes). Initially, the first author developed a descriptive mapping between CT and MT, supported by analytical coding fragments as evidence. The co-authors then reviewed the relevant claims and rationales, and refined codes through discussion. The initial codes were: “mathematical concept”, “mathematical process”, “CT concept”, “translation”, and “integration”, reflecting our interest in the relationship between MT and CT. In Phase 3 (Searching for themes), the first author then assigned labels to the programming code segment to help the research team collate codes into potential themes. Based on the characteristics of CT and MT from the data set, we gathered all data relevant to each potential theme.

To make the themes clearer, the first author suggested theme names and corresponding descriptions to check whether the themes were related to coded extracts in Phase 4 (Reviewing themes). Early themes included “MT flexibility”, “CT flexibility”, “Transfer flexibility” and “Integrated flexibility”. All authors then discussed and examined the initial themes and corresponding data. After iterative discussions, we decided to focus on segments where both MT and CT were present based on the research context (i.e., programming-based mathematics learning environment), while ignoring MT flexibility and CT flexibility alone. In Phase 5 (Defining and naming themes), we focused on the similarities and differences within and between themes in an ongoing analysis to refine the definition and names of the themes, and finally identified two kinds of flexibility: Translation flexibility and Integrated flexibility. In particular, “translation flexibility” is renamed from “transfer flexibility” and we have formed two sub-themes (conceptual translation and procedural translation) under this topic by distinguishing mathematical concepts and processes underlying the code. We further sub-categorized three different forms (direct, indirect, indirect CT-based) of CT and MT expressions under these two sub-themes. Finally, in Phase 6 (Producing the report), we recoded the data and linked the research question by looking back at the updated themes and definitions to ensure the validity and consistency of coding. Then, we selected fragments of programming solutions as examples to report our findings in the next section. We summarize the definitions of themes in Table 2.

Table 2.

Definition of Themes.

Level of Theme	Type of Flexibility	Definition
First-level	1. Translation flexibility	A cross-disciplinary, cross-problem context capability, refers to when problem solvers choose an appropriate strategy to translate mathematical language (expression) to programming language (solution) in a given programming environment, where this process involves one to work across MT and CT.
Second-level	1.1 Conceptual translation	Refer to choosing a strategy for expressing certain mathematical concepts, including various equivalent expressions, in a programming context, and which does not change according to the problem situation.
Third-level	1.1.1 Direct conceptual translation	Use built-in functional commands or instruction codes that explicitly map to certain mathematical concepts.
	1.1.2 Indirect conceptual translation	Transform the target mathematical expression into other equivalent representations (either mathematically or computationally) before using built-in functional commands.
	1.1.3 Indirect CT-based conceptual translation	Reinterpret mathematical statements by further breaking them down into a series of programming steps from a CT perspective.
Second-level	1.2 procedural translation	Refer to the different ways of executing mathematical procedures to carry out the problem solution in a programming context.
Third-level	1.2.1 Direct procedural translation	Reproduce certain mathematical or problem-solving process in a programming solution the same as its original form.
	1.2.2 Indirect procedural translation	Reinterpret some mathematical procedures that are not possible to perform directly in a programming language with other procedures in a programming context.
	1.2.3 Indirect CT-based procedural translation	Reinterpret or reorganize some mathematical procedures by taking advantage of CT concepts in a programming environment.
First-level	2. Integrated flexibility	A holistic capability resembling the kinds of flexibility needed for a mathematical problem context in general, refers to the capability to orchestrate CT and MT strategies when generating different programming solutions.

Results

By thematically analysing the participants’ problem-solving strategies and programming-based mathematical solutions, we arrived at two kinds of flexibility, namely translation flexibility and integrated flexibility.

Translation Flexibility: Conceptual Translation Flexibility

Translation flexibility refers to a cross-disciplinary, cross-problem-context capability that problem solvers choose an appropriate strategy to translate mathematical language (expression) to programming language (solution) in a given programming environment, where this process involves one work across MT and CT. Based on the difference in mathematical expressions (concepts or procedures), translation flexibility can further be sub-categorized into conceptual translation and procedural translation. Conceptual translation flexibility refers to choosing a strategy for expressing certain mathematical concepts, including various equivalent expressions, in a programming context, and which does not change according to the problem situation. First, we illustrate our observed subcategories of conceptual translation flexibility in Table 3, followed by descriptions of each.

Table 3.

Different Subcategories of Conceptual Translation Flexibility.

Translation Flexibility	Mathematical Expression	Related Task Description
Direct conceptual translation	X is a random number between 1 and 6	In one probability task, a randomize function was used to simulate dice rolling and obtaining a number between 1 to 6
Indirect conceptual translation	X is an integer	In the prime number detector task, it was first necessary to determine whether the input number was an integer or not
Indirect CT-based conceptual translation	X is a prime number	In the prime number detector task, the properties of the prime number (i.e., x is a positive integer which has only two factors, namely 1 and itself) were considered to determine whether the input number was prime or not

Direct Conceptual Translation

Direct conceptual translation occurs when the programmer uses a programming tool with built-in functional commands or instruction codes that explicitly map to certain mathematical concepts. This makes it possible for programmers to express mathematical ideas directly in the programming environment without having to write new code to carry out the function which is connected to a mathematical concept. For instance, when a programmer wants to select a random number between 1 and 6, they can use the [pick random X to Y] block to translate such expression; this type of translation suggests that the mathematical concepts can be transferred into a programming language virtually without requiring concept transformation.

Indirect Conceptual Translation

By comparison, we observe that due to the discrepancies between programming language and mathematical language, one may not be able to express a mathematical concept directly in the programming environment. Instead, it may be necessary to transform the target mathematical expression into other equivalent representations (either mathematically or computationally) to convey the same concept in the programming language, and we refer this as indirect conceptual translation. For example, since there is no direct block in Scratch for determining whether a number is an integer, when the programmer wants to apply this condition, it is necessary to make sense of the concept of integer in other ways. Observing the fact that an integer satisfies the following mathematical statements: round X = X, ceil X = X, floor X = X, one can then translate the relevant statements into a programming language directly, since the codes [round X], [ceil X], [floor X] are already available in Scratch. Thus, the difference between the two types of translation is that direct conceptual translation requires no transformation of the coder’s existing mathematical concepts, since the programming tool already has the syntax to express them, whereas indirect conceptual translation calls for the coder to first perform an equivalent transformation of the mathematical concept before applying the code instructions. If the coder is unable to flexibly transform the mathematical concepts in an equivalent way, they may find it difficult to represent their mathematical thinking in a programming environment.

However, we note that direct and indirect conceptual translations are not mutually exclusive. In a programming context, some mathematical concepts can be expressed both by direct translation and by indirect translation. For example, the mathematical expression “The ones digit of a two-digit number, XY” can either be expressed directly using the Scratch block [letter N of XY], or it can also be transformed into an equivalent concept of: “The remainder when a two-digit number is divided by 10” and then coded as [XY mod 10] (Table 4). Thus, there is also flexibility between the two types of translations, and the lens of flexibility offers a way to understand the multiple strategies involved as well as the type of translation chosen as an effective strategy by the problem solver.

Table 4.

Example of the Same Mathematical Concept With Different Programming Expression Translations.

Translation Flexibility	Mathematical Expression	Programming Expression in scratch
Direct conceptual translation	The ones digit of a two-digit number XY is 0
Indirect conceptual translation	The ones digit of a two-digit number XY is 0

Indirect CT-based Conceptual Translation

It is noteworthy that not every mathematical concept can be translated into an equivalent expression using a single line of code. Typically, a mathematical statement is taken as a “given is true” sentence without needing further elaboration. However, to enable the realization of certain mathematical propositions in a programming context, the meaning of these “given as true” propositions may need to be reinterpreted by further breaking it down into a series of programming steps to check whether they are indeed true. We refer this type of translation as indirect CT-based conceptual translation. Taking the example of the mathematical proposition “x is a prime number,” it would be taken as true that “x is a positive integer which has only 2 factors, namely 1 and itself”. We note that this meaning does not mention “the remainder” and “all positive integers between 1 and x”; however, when translating the proposition in a programming context, a programmer would need to reinterpret the proposition as testing the number of factors of x. From Table 3, we can see that the programming reinterpretation called upon the use of [repeat until…] (a computational or CT concept of loop, Ye et al., 2023) along with a [if…then…] block (a computational or CT concept of conditional, Ye et al., 2023) to execute the testing. While a loop is used to find the possible factor of x, a conditional is used to determine whether x has a factor different 1 and itself. Therefore, one needs to reinterpret the proposition according to the mathematical properties by making use of several CT concepts, that is, to test the number of factors of x so as to realize “x is a prime number if the remainder of a positive integer x divided by any number between 2 and x-1 is non-zero”. We consider such programming practices as demonstrating CT while being markedly different from the original mathematical proposition, “x is a prime number”, and hence, the sub-category, indirect CT-based conceptual translation.

Summary

Of the three sub-categories of conceptual translation flexibility, we suggest that the latter two—indirect conceptual translation and indirect CT-based conceptual translation—should receive more attention, as they both involve problem solvers having a deeper understanding of the nature of mathematical concepts, as well as making connections and transformations. In a programming environment, the same mathematical concept can be interpreted in different ways, which may affect how effective the problem-solving strategies become. Conversely, it is the differences between mathematical expressions and programming languages that stimulate problem solvers to strengthen the connections between mathematical concepts in a programming context. Thus, these two types of translation flexibility demand a high level of MT of the problem solver. Specifically, indirect conceptual translation examines the competence to identify connections between mathematical concepts; whereas indirect CT-based conceptual translation concerns the role of boundary crossing between MT and CT (Ng et al., 2023). Problem solvers demonstrating the latter have to learn to interpret mathematical concepts from a CT perspective, which will help them to generate a new insight into mathematical concepts, that is, this kind of translation will become a new way to understand mathematics.

Translation Flexibility: Procedural Translation Flexibility

As another type of translation flexibility, procedural translation flexibility refers to the different ways of executing mathematical procedures to carry out the problem solution, which most often changes depending on the problem situation. It involves choosing a strategy for expressing certain mathematical procedures, including algorithm execution and problem solving, in a programming context. In the following, we illustrate three subcategories of this type of flexibility, namely direct procedural translation, indirect procedural translation, and indirect CT-based procedural translation in a programming-based mathematical problem-solving context (Table 5).

Table 5.

Different Subcategories of Procedural Translation Flexibility.

Translation Flexibility	Mathematical expression	Related Task Description
Direct procedural translation	Translate (x, y) to (x+10, y+20)	In the introductory game design, the shooting target (a bat) should be programmed to move forward by itself, and this can be achieved by repeatedly changing the bat’s position in the x-y coordinate plane
Indirect procedural translation	Make a 30° angle	In the polygon drawing task, the participants were prompted “to write a program which would draw different regular polygons of different size”; this calls for drawing interior angles of the polygon, from which the size of its complementary exterior angle needs to be considered
Indirect CT-based procedural translation	18 + 21 + 24 + … (25 terms in total)	In the concert Hall seat problem satisfying an arithmetic series (first term is 18, common difference is 3, number of terms is 25), to calculate the total number of seats, then need to consider the mathematical relationships between the different variables and the summation strategy (e.g., using loops for superposition)

Direct Procedural Translation

Direct procedural translation refers to using programming tools and language to reproduce certain mathematical or problem-solving processes in their original form. For example, when one translates a point (x, y) to (x+10, y+20), one can directly use the code [go to x + a, y + b] to perform the translation (in a mathematical sense). This example demonstrates how a programmer’s mathematical and problem-solving procedure can be transferred into a programming language directly without changing its form and structure, which we define as direct procedural translation.

Indirect Procedural Translation

By comparison, some mathematical procedures are not possible to perform directly in a programming language. In such cases, the problem solver needs to reinterpret them with different procedures to achieve the same result. For example, when one makes a 30-degree angle, a typical approach in mathematics is to draw two lines which meet at a vertex, where the angle contained by the two lines is 30°. However, in Scratch, there are no commands to make angle, per se. Instead, a programmer needs to focus on the trajectory of a Pen, i.e., to think of tracing a Pen in a certain direction and then making a turn from that direction. Therefore, to draw a 30-degree angle requires the Pen to move along a straight path and then to [turn counterclockwise 150°]. In doing so, the problem solver needs to reflect on more problem-related knowledge to solve the problem from a different perspective. In the case of drawing angles in a programming environment, the problem solver’s concern for the rotation angle and direction is more apparent than in a paper-and-pencil context, so the problem solver needs to take into account that 30° and 150° are supplementary (i.e. add to 180°) and thus perform a 180°–30° = 150° rotation to the left (meaning counter-clockwise) to draw the 30° angle.

Indirect CT-based Procedural Translation

Similar to indirect CT-based conceptual translation, indirect CT-based procedural translation necessitates a reinterpretation of mathematical processes by taking advantage of CT concepts, such as iteration and loops, when engaging in programming-based mathematical problem-solving. We illustrate this flexibility with the example of determining the arithmetic series $18 + 21 + 24 + \dots (25 t e r m s)$ , which means to calculate the sum of the 25 terms which followed an arithmetic sequence. Given that Scratch is not equipped with a relevant direct function of SUM (numbers), as found in Excel, an efficient approach to obtain the result is to change the structure of the calculation process to produce the sum. That is, rather than calculating the sum at once, we can use an iterative strategy to determine the sum by adding the first two terms initially, and then adding the subsequent term to the previous sum, and so on. Form the sample codes in Table 5, we can see that the problem solver has used [set X to Y] and [change sum by term] blocks to identify the quantitative relationship between the terms, which also draws on the CT concept, variable. Also, the use of [repeat X] was called upon to represent the total number of terms and the number of times to perform the sum, which is related to another CT concept, loop. Such an iterative programmable calculation procedure is different from what we do in a paper-and-pencil context, and we regard it as indirect CT-based procedural translation.

Summary

Translation flexibility is emphasised as an interdisciplinary competence in the context of a problem situation that contains two disciplines, programming and mathematics, through which problem solvers incorporate mathematical ideas into a programming solution. However, this does not mean that there is only one programming approach corresponding to the mathematical solution strategy. We take the example of drawing an equilateral triangle (Table 6), which can be achieved either by indirect procedural translation or by indirect CT-based procedural translation. Akin to our discussion of conceptual translation flexibility, it is important to note that indirect procedural translation considers the transformation of mathematical relationships, whereas indirect CT-based procedural translation demands a link between mathematics and CT, examining the problem solver’s integration of MT and CT.

Table 6.

Different Procedural Translations to Draw an Equilateral Triangle in Scratch.

Indirect procedural translation		Indirect CT-based procedural translation
	Simulate each step of the drawing process of an equilateral triangle by corresponding the codes line-by-line, without using the CT concept of loop		By recognizing the drawing pattern, the CT concept of the loop (i.e. [repeat 3]) is used to demonstrate the repeated process of [move 100 steps, turn clockwise 120°]

Overall, procedural translation flexibility refers to the different ways of solving a given problem, which most often varies depending on the problem situation. On the other hand, conceptual translation flexibility refers to working with various equivalent expressions of a mathematical concept that are independent of the nature of the problem but related to the nature of the concept. As such, if there is a significant gap between one’s MT and CT, it might be challenging to convert mathematical ideas into programming solutions.

Integrated Flexibility

Different from translation flexibility which focuses on the translation process of mathematical ideas to programming solutions, we characterize a second type of flexibility demonstrated in the programming-based mathematical problem-solving process, namely integrated flexibility. It is a holistic kind of capability resembling the kinds of flexibility needed for a mathematical problem context in general (e.g., to solve an algebra equation; Star & Seifert, 2006), which orchestrates CT and MT strategies when generating different programming solutions, with the MT and CT realisations being inseparable as a whole. Since different CT strategies can be used to represent the same contents, the related programming solutions to the mathematical problem will also change correspondingly or vice versa, and thus the MT strategy must be compatible with the CT approach. In this section, we will use a geometry example to illustrate the features of integrated flexibility.

One of the most evident examples of integrated flexibility is the setup of subroutines, often known as creating My Blocks in Scratch. As an important CT concept, subroutines can be divided into two types. One is a parameterless subroutine, which calls an entire set of codes without altering any elements in it but rather gives it a name for identification. For example, a subroutine named “Pentagon” was set in Figure 1(b) and the codes are identical to the ones in Figure 1(a). In other words, this type of subroutine does not require coders to make any adjustments to the codes; whereas those subroutines with parameters require coders to identify key attributes and numerical relationships between them, and then modify the codes by abstracting parameters (Figure 1(c)). In this section, we will focus on subroutines with parameters and examine the related integrated flexibility through a Polygon Drawing task.

Figure 1.

Drawing a pentagon in Scratch (a) without, or (b)–(d) with using My Block as a subroutine.

When tasked with drawing a regular polygon in a paper-and-pencil context, one would consider the polygon’s side length, and the degree of interior angles, and then draw it with a ruler and a protractor. Whereas to achieve this mathematical process in Scratch, the Pen function is used to record the trajectory of a Sprite. For example, to draw a regular pentagon with side lengths of 50 units, the Pen would need to be programmed to [move 50 steps] followed by [turn clockwise 72°], repeating this process five times in total (Figure 1(a)). The code at this point does not yet make use of a subroutine, but if the programmer attempts to simplify the programming steps and to design a program that the size and shape of the polygon could vary, MT and CT are required for setting parameters in the subroutine (Figure 1(c)–(d)), and hence integrated flexibility is called upon.

As characterized by integrated flexibility, the process of changing the original codes (Figure 1(a)) to a set of codes with subroutines (Figure 1(c)–(d); Figure 2(a)–(b)) requires the integration of MT and CT. For example, the problem solver could abstract a parameter “side_length” in My Block which would replace numbers in the source code that represent the side length of the polygon, and the subsequent subroutine would serve to control the size of a pentagon. Such a change is mediated by CT and MT, such as figuring out which value represents the side length, which can be replaced by a parameter in the subroutine. Hence, CT supports problem solvers in creating subroutines, while MT helps determine the parameter (i.e., the length of the sides, which also determines the size of the polygon) in the subroutines. As one attempt to optimize the subroutine to vary the shape of the polygon, not only should one draw upon the idea that the exterior angles would change accordingly, but also need to reconsider the CT concept of loop to control the repeated times of [move X steps] and [turn clockwise X degrees] blocks. Otherwise, the subroutine with parameter “exterior_angle” in Figure 1(d) will not draw any regular polygon other than a regular pentagon. Hence, the key to solving such problems is the effective coordination of CT and MT.

Figure 2.

Setting of My Blocks as subroutine.

Therefore, a third parameter might come into play in the subroutine, as shown in Figure 2(a), when the problem solver further abstracted the repeatable programming steps with a loop and with a new parameter, “number_of_sides”, which controls the number of times the loop is executed. Specifically, the MT required is the same two quantitative relationships among the three parameters used in the subroutines, namely: interior angle $α = 180 (n - 2) / n °$ and exterior angle $β = 180 ° - α$ . We highlight that, here, the CT concept of loop was demonstrated, and can be utilised to further optimise the subroutine through advancing one’s MT. That is, the codes in Figure 2(b) reflect that the problem solver had recognized that $β = 360 ° / n$ , which suggests that the size and shape of a regular polygon can be determined by only two parameters, “side_length” and “number_of_sides,” since the number of sides already implicates the exterior angles of the polygon. Altogether, this example reveals the synergy between CT and MT in the process of setting subroutines with parameters. Thus, we observe that during the process of creating subroutines, the CT concepts (of subroutines and loops) and MT (of geometrical properties, such as $α = 180 (n - 2) / n °$ , $β = 180 ° - α$ , and ultimately $β = 360 ° / n$ ) facilitate, yet constrain, each other in the sense that the CT concepts play a key role in supporting the adaptation of the program, while the quantitative relationships involved in MT are responsible for decision making on how to set up the parameters in the subroutine, including the choice of using which CT concepts and how they are used. For example, integrated flexibility is demonstrated through recognizing that the number of sides determines the number of loops; and that the parameters in the subroutines are the attributes that control size and shape—the length and the number of sides—respectively. It is the integrative effect of CT and MT that supports problem solvers to abstract the key parameters which determine the size and shape of a regular polygon. We reiterate that when solving mathematical problems in a programming context demonstrating integrated flexibility, CT and MT co-exist and support each other.

Discussion

Drawing on the perspective of flexibility from mathematics education research, this study extended the construct of flexibility to the context of programming-based mathematical problem-solving. We propose a conceptual framework that encompasses translation flexibility and integrated flexibility by thematic analysis. Translation flexibility refers to the ability to translate mathematical concepts or processes into the target programming language. Integrated flexibility presents the ability to orchestrate CT and MT in different programming solutions adeptly. The characterizations of different (sub-)types of flexibility emerging from the thematic analyses have the potential for understanding the mutual cognitive development in CT and MT, including how mathematical concepts co-emerge with programming processes in a problem-solving context, and the role of CT and MT in such processes. In the following, we discuss the observed interplay between CT and MT in terms of deepening one’s conceptual learning, co-developing one’s CT and MT, and how flexibility was mediated by the programming environment, including the facilitations and constraints that it brought forward, during programming-based mathematical problem-solving.

Firstly, both conceptual and procedural translation, particularly, indirect and indirect CT-based translation provides problem solvers with opportunities to deepen their understanding of mathematical concepts by taking advantage of the difference between programming and mathematical languages. These opportunities are highlighted by the features and functions of the programming tool. In some cases, even implementing simple mathematical concepts or procedures within a programming environment can become relatively complex, and this presents opportunities for the problem solvers to reorient their MT in ways that may facilitate conceptual learning. For example, in the case of using Scratch to draw triangles and polygons drawn upon indirect CT-based procedural translation, it potentially offers conceptual learning of the relationship between the number of sides of a polygon and its exterior angle. Through observing the code patterns, the students may learn to infer the turning angle as calculated by 360/n also represents the degree of exterior angle of an n-sided polygon. It is during the programming process that the CT concepts of “variable” and “loops” occasion students to express mathematically in different ways, thus enhancing their geometry knowledge. In another case “to express the digits of a number XY”, instead of directly recognising X and Y as what can be seen, the indirect conceptual translation requires a deeper understanding of the relationship between the digits and the value they represent by using the code [mod 10]. We note that the same mathematical principle can be extended to other numeral systems, such as binary numbers, and this makes the combination of programming and mathematical practice powerful, as it advances one’s flexibility in working with a concept in different systems. As Ye et al. (2023, p. 14) reviewed, a variable manifests as a “numerical, algebraic or geometric representation of an entity whose values can be stored, retrieved and operated on”, which refers to the quantitative relationship between the numbers being operated in a programming context. In this study, the participants made the connection between mathematics and programming by naming, initializing, and using variables to represent the digit value of the number, XY. As Cai et al. (2005) argue, early exposure to variables can support learning algebraic concepts, and therefore, the findings of this study are significant in supporting participants’ conceptual development in algebra.

Secondly, we turn to integrated flexibility, which pertains to the intricate interaction between MT and CT. This interaction significantly differs from the unidirectional conversion from one (i.e., mathematical or programming) language to another through translation flexibility. When engaging in integrated flexibility, it is vital to consider the compatibility of the selected mathematical and computation approaches. If the two align, it will potentially afford the co-development of CT and MT. For instance, in the geometry task, the participant may transition from a basic solution to a more advanced one, as shown in the results. In this process, interactions between CT and MT may occur; one such interaction could involve employing the CT concept of “loop” to simplify the codes by recognizing the repetition patterns. Simultaneously, the participants may also discover the mathematical relationship between the number of repetitions, the number of sides, and the turning angle (Cui et al., 2023; Miller, 2019). This situation illustrates how CT can support MT. Conversely, the participant could initially determine the mathematical characteristics of a regular polygon (i.e., all sides and internal angles are equal). Following this, they could use the CT concept of loop to express these characteristics, demonstrating how MT can facilitate CT. This bi-directional support system between CT and MT highlights the concept of integrated flexibility in problem-solving. However, the selected mathematical and computational approaches may not always align seamlessly. In this case, we suggest that adjustments ought to be made within the shared context to devise an effective programming solution. This process, while seemingly constraining, the programming constraints could also become a venue which contributes to the growth of CT and MT.

The findings of this study also culminate in mathematics and programming education in cross- and interdisciplinary contexts. As shown in this study, translation flexibility is a cross-disciplinary, cross-problem-context competence, while integrated flexibility is an interdisciplinary competence that extends current research on flexibility in mathematics education research (Newton et al., 2020; Rittle-Johnson & Star, 2007; Star et al., 2022; Star & Seifert, 2006). i.e., integrated flexibility relates to solving mathematical problems in a programming environment by drawing upon knowledge from both mathematics and programming disciplines. Noting that the characteristics of flexibility are not hierarchical but intertwined, we propose that the characteristics can serve to develop a conceptual framework focusing on the flexibility exhibited in programming-based mathematical problem-solving. In particular, we evidenced that flexibility is often associated with CT concepts, such as variables, subroutines, loops, and conditionals. Meanwhile, future research may consider demonstrating the flexibility associated with CT practices, such as the identification of different ways of constructing mathematical artefacts (e.g., geometric shapes); decomposition; pattern recognition; modelling and simulation; as well as testing and debugging by drawing upon mathematical and programming knowledge.

As programming is a tool-mediated activity, we acknowledge that different programming tools are instrumented differently, prompting diverse CT-MT translations and interactions to occur. Therefore, the study is limited in that we only consider the types of flexibility demonstrated in programming-based mathematical problem-solving as Scratch-mediated activity. While our examples are illustrated using the specific tool, we speculate that the nature of the two types of flexibility may be common across various programming tools. i.e., the given examples of flexibility are tool-specific, the kinds of flexibility and their features are tool-general and may occur across programming environments. For example, in a text-based programming tool with functions to determine integers (e.g., in Python, the function, ‘int’), determining whether a number is an integer can be easily achieved using the condition “if type (x) = = int”. This negates the need for indirect translation such as “round X = X” in Scratch. However, when dealing with other mathematical concepts that do not have direct instructions, problem solvers still need to convert their ideas between languages when it arises that the target programming language does not entirely match the mathematical language. Thus, further research is required to examine the kinds of flexibility in different programming tools to better understand the interplay between CT and MT in a programming-based mathematical problem-solving context.

Conclusion

This research aims to contribute to a deeper understanding of the interplay of CT and MT, providing a foundation for conceptualizing an interdisciplinary form of mathematics and programming education. It also informs task and pedagogical designs of programming-based mathematics instruction. Moreover, the findings offer theoretical contributions that inform mathematics education researchers and practitioners in terms of student learning characteristics during programming-based mathematics instruction. As our data from two different participant groups exhibit some comparable features of flexibility, we suggest that there is a certain generality about flexibility when problem solvers tackling with programming-based mathematical problems. We encourage further research to consider the different kinds of flexibility demonstrated in programming-based mathematical problem-solving to sketch the big picture of how CT and MT emerge in complementary or mismatching ways.

Footnotes

Acknowledgments

This study was fully supported by the Research Grants Council, General Research Fund (Ref. No. 14603720).

Declaration of Conflicting Interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the Hong Kong Research Grants Council; General Research Fund (Reference No. 14603720)

ORCID iDs

Huiyan Ye

Oi-Lam Ng

Zhihao Cui

Author Biographies

Huiyan Ye is a PhD student in the Department of Curriculum and Instruction at The Chinese University of Hong Kong, where she served as a research assistant before her PhD study. Her research interests focus on technologies for mathematics teaching and learning. Particularly, she is interested in the integration of computational thinking and mathematics education.

Oi-Lam Ng is an Associate Professor in the Department of Curriculum and Instruction at The Chinese University of Hong Kong. Her research interests include technology innovations in mathematics education, language and mathematics discourse, teacher noticing, and STEM education. Particularly, she is interested in advancing a Papert-inspired conception of “learning as Making,” and the new opportunities it entails for engaging learners in constructionist practices with emergent technologies (3D printing, coding etc).

Zhihao Cui is a PhD candidate in the Department of Curriculum and Instruction at The Chinese University of Hong Kong. His recent work focuses on the development and interaction of computational and mathematical thinking and technology-supported mathematical learning. His research interests include constructionism-inspired teaching and learning, technology-supported STEM education, and technology innovations in mathematics education.

References

Barr

Stephenson

(2011). Bringing computational thinking to K-12: What is involved and what is the role of the computer science education community? Acm Inroads, 2(1), 48–54. https://doi.org/10.1145/1929887.1929905

Braun

Clarke

(2006). Using thematic analysis in psychology. Qualitative Research in Psychology, 3(2), 77–101. https://doi.org/10.1191/1478088706qp063oa

Burton

(1984). Mathematical thinking: The struggle for meaning. Journal for Research in Mathematics Education, 15(1), 35–49. https://doi.org/10.2307/748986

Cai

Lew

H. C.

Morris

Moyer

J. C.

Fong Ng

Schmittau

(2005). The development of studients’ algebraic thinking in earlier grades: A cross-cultural comparative perspective. Zentralblatt für Didaktik der Mathematik, 37(1), 5–15. https://doi.org/10.1007/BF02655892

Cui

(2021). The interplay between mathematical and computational thinking in primary school students’ mathematical problem-solving within a programming environment. Journal of Educational Computing Research, 59(5), 988–1012. https://doi.org/10.1177/0735633120979930

Cui

Jong

M. S.-Y.

(2023). Integration of computational thinking with mathematical problem-based learning: Insights on affordances for learning. Educational Technology and Society, 26(2), 131–146. https://doi.org/10.30191/ETS.202304_26(2).0010

Dickes

A. C.

Farris

A. V.

Sengupta

(2020). Sociomathematical norms for integrating coding and modeling with elementary science: A dialogical approach. Journal of Science Education and Technology, 29(1), 35–52. https://doi.org/10.1007/s10956-019-09795-7

Echeverria

Cobos

Morales

(2019). Improving the students computational thinking skills with collaborative learning techniques. IEEE Revista Iberoamericana de Tecnologias Del Aprendizaje, 14(4), 196–206. https://doi.org/10.1109/RITA.2019.2952299

Feldhausen

Weese

J. L.

Bean

N. H.

(2018). Increasing student self-efficacy in computational thinking via STEM outreach programs. In SIGCSE 2018 - Proceedings of the 49th ACM Technical Symposium on computer science education. Association for Computing Machinery, 2018, 302–307. https://doi.org/10.1145/3159450.3159593

10.

Jocius

Ian O’byrne

Albert

Joshi

Robinson

Andrews

(2021). Infusing computational thinking into STEM teaching. Technology in Society, 24(4), 166–179. https://doi.org/10.2307/48629253

11.

Kaufmann

O. T.

Stenseth

(2021). Programming in mathematics education. International Journal of Mathematical Education in Science and Technology, 52(7), 1029–1048. https://doi.org/10.1080/0020739X.2020.1736349

12.

Miller

(2019). STEM education in the primary years to support mathematical thinking: Using coding to identify mathematical structures and patterns. ZDM - Mathematics Education, 51(6), 915–927. https://doi.org/10.1007/s11858-019-01096-y

13.

Newton

K. J.

Lange

Booth

J. L.

(2020). Mathematical flexibility: Aspects of a continuum and the role of prior knowledge. The Journal of Experimental Education, 88(4), 503–515. https://doi.org/10.1080/00220973.2019.1586629

14.

Cui

(2021). Examining primary students’ mathematical problem-solving in a programming context: Towards computationally enhanced mathematics education. ZDM – Mathematics Education, 53(4), 847–860. https://doi.org/10.1007/s11858-020-01200-7

15.

Leung

(2023). Exploring computational thinking as a boundary object between mathematics and computer programming for STEM teaching and learning. ZDM – Mathematics Education. https://doi.org/10.1007/s11858-023-01509-z

16.

Liu

Cui

(2021). Students’ in-moment challenges and developing maker perspectives during problem-based digital making. Journal of Research on Technology in Education, 55(3), 411–425. https://doi.org/10.1080/15391523.2021.1967817

17.

Nowell

L. S.

Norris

J. M.

White

D. E.

Moules

N. J.

(2017). Thematic analysis: Striving to meet the trustworthiness criteria. International Journal of Qualitative Methods, 16(1), 160940691773384. https://doi.org/10.1177/1609406917733847

18.

Pei

C. (Yu)

Weintrop

Wilensky

(2018). Cultivating computational thinking practices and mathematical habits of mind in Lattice Land. Mathematical Thinking and Learning, 20(1), 75–89. https://doi.org/10.1080/10986065.2018.1403543

19.

Piaget

Inhelder

(1968). The psychology of the child. Basic Books.

20.

Rich

K. M.

Strickland

Binkowski

T. A.

Moran

Franklin

(2018). K-8 learning trajectories derived from research literature: Sequence, repetition, conditionals. ACM Inroads, 9(1), 46–55. https://doi.org/10.1145/3183508

21.

Rittle-Johnson

Star

J. R.

(2007). Does comparing solution methods facilitate conceptual and procedural knowledge? An experimental study on learning to solve equations. Journal of Educational Psychology, 99(3), 561–574. https://doi.org/10.1037/0022-0663.99.3.561

22.

Rodríguez-Martínez

J. A.

González-Calero

J. A.

Sáez-López

J. M.

(2020). Computational thinking and mathematics using Scratch: An experiment with sixth-grade students. Interactive Learning Environments, 28(3), 316–327. https://doi.org/10.1080/10494820.2019.1612448

23.

Sáez-López

J.-M.

Sevillano-García

M.-L.

Vazquez-Cano

(2019). The effect of programming on primary school students’ mathematical and scientific understanding: Educational use of mBot. Educational Technology Research & Development, 67(6), 1405–1425. https://doi.org/10.1007/s11423-019-09648-5

24.

Selter

(2009). Creativity, flexibility, adaptivity, and strategy use in mathematics. ZDM, 41(5), 619–625. https://doi.org/10.1007/s11858-009-0203-7

25.

Sinclair

Patterson

(2018). The dynamic geometrisation of computer programming. Mathematical Thinking and Learning, 20(1), 54–74. https://doi.org/10.1080/10986065.2018.1403541

26.

Star

J. R.

Newton

Pollack

Kokka

Rittle-Johnson

Durkin

(2015). Student, teacher, and instructional characteristics related to students’ gains in flexibility. Contemporary Educational Psychology, 41(2), 198–208. https://doi.org/10.1016/j.cedpsych.2015.03.001

27.

Star

J. R.

Seifert

(2006). The development of flexibility in equation solving. Contemporary Educational Psychology, 31(3), 280–300. https://doi.org/10.1016/j.cedpsych.2005.08.001

28.

Star

J. R.

Tuomela

Joglar-Prieto

Hästö

Palkki

Abánades

M. Á.

Pejlare

Jiang

R. H.

Liu

R.-D.

(2022). Exploring students’ procedural flexibility in three countries. International Journal of STEM Education, 9(1), 4. https://doi.org/10.1186/s40594-021-00322-y

29.

Sung

Ahn

Black

J. B.

(2017). Introducing computational thinking to young learners: Practicing computational perspectives through embodiment in mathematics education. Technology, Knowledge and Learning, 22(3), 443–463. https://doi.org/10.1007/s10758-017-9328-x

30.

Verschaffel

Luwel

Torbeyns

Van Dooren

(2009). Conceptualizing, investigating, and enhancing adaptive expertise in elementary mathematics education. European Journal of Psychology of Education, 24(3), 335–359. https://doi.org/10.1007/BF03174765

31.

Von Glasersfeld

(1995). Radical constructivism: A way of knowing and learning. Falmer Press.

32.

Weng

Cui

Jong

M. S. Y.

Chiu

T. K. F.

(2022). Characterizing students’ 4C skills development during problem-based digital making. Journal of Science Education and Technology, 31(3), 372–385. https://doi.org/10.1007/s10956-022-09961-4

33.

Weng

Cui

Leung

(2022). Creativity development with problem-based digital making and block-based programming for Science, Technology, Engineering, Arts, and Mathematics learning in middle school contexts. Journal of Educational Computing Research, 61(2), 304–328. https://doi.org/10.1177/07356331221115661

34.

Wing

J. M.

(2006). Computational thinking. Communications of the ACM, 49(3), 33–35. https://doi.org/10.1145/1118178.1118215

35.

Wing

J. M.

(2008). Computational thinking and thinking about computing. Philosophical transactions. Series A, Mathematical, physical, and engineering sciences, 366(1881), 3717–3725. https://doi.org/10.1098/rsta.2008.0118

36.

Wing

J. M.

(2011). Research notebook: Computational thinking—what and why. The Link Magazine, 6, 20–23. http://link.cs.cmu.edu/files/11-399_The_Link_Newsletter-3.pdf

37.

Liang

Chai

C. S.

(2023). Integration of computational thinking in K-12 mathematics education: A systematic review on CT-based mathematics instruction and student learning. International Journal of STEM Education, 10(1), 3. https://doi.org/10.1186/s40594-023-00396-w