Treffer: Parallel Instruction of Text-Based and Block-Based Programming: On Novice Programmers' Computational Thinking Practices

Title:
Parallel Instruction of Text-Based and Block-Based Programming: On Novice Programmers' Computational Thinking Practices
Language:
English
Authors:
Minji Jeon (ORCID 0000-0002-0301-2221), Kyungbin Kwon (ORCID 0000-0001-8646-0144)
Source:
TechTrends: Linking Research and Practice to Improve Learning. 2024 68(6):1033-1050.
Availability:
Springer. Available from: Springer Nature. One New York Plaza, Suite 4600, New York, NY 10004. Tel: 800-777-4643; Tel: 212-460-1500; Fax: 212-460-1700; e-mail: customerservice@springernature.com; Web site: https://link.springer.com/
Peer Reviewed:
Y
Page Count:
18
Publication Date:
2024
Document Type:
Fachzeitschrift Journal Articles<br />Reports - Research
Education Level:
Higher Education
Postsecondary Education
DOI:
10.1007/s11528-024-00993-8
ISSN:
8756-3894
1559-7075
Entry Date:
2024
Accession Number:
EJ1450941
Database:
ERIC

Weitere Informationen

This study investigated the computational thinking (CT) practices of eight pre-service teachers through their Scratch and Python programs. Conducted within an undergraduate-level computer science education course, students learned CT concepts via parallel instruction in block-based programming (Scratch) and text-based programming (Python). The research focused on the synergistic effects of this parallel instruction, investigating how novices' CT practice evolved while encountering unique features of each environment. Findings indicated that students' CT practices in one programming environment positively influenced their practices in the other, particularly where syntactic similarities existed. Overall, their strategies for controlling program flow progressed from time-based controls to message-passing controls, and finally to condition-based controls. However, the students demonstrated a lack of abstracting and modularizing skills in their computational problem-solving across both programming environments.

As Provided

AN0181199124;ttr01nov.24;2024Dec02.04:33;v2.2.500

Parallel Instruction of Text-based and Block-based Programming: On Novice Programmers' Computational Thinking Practices 

This study investigated the computational thinking (CT) practices of eight pre-service teachers through their Scratch and Python programs. Conducted within an undergraduate-level computer science education course, students learned CT concepts via parallel instruction in block-based programming (Scratch) and text-based programming (Python). The research focused on the synergistic effects of this parallel instruction, investigating how novices' CT practice evolved while encountering unique features of each environment. Findings indicated that students' CT practices in one programming environment positively influenced their practices in the other, particularly where syntactic similarities existed. Overall, their strategies for controlling program flow progressed from time-based controls to message-passing controls, and finally to condition-based controls. However, the students demonstrated a lack of abstracting and modularizing skills in their computational problem-solving across both programming environments.

Keywords: Block-based programming; Computational thinking practice; Novice programming; Parallel instruction; Text-based programming

Minji Jeon is assigned as Corresponding Author and acts on behalf of all co-authors and ensures that questions related to the accuracy or integrity of any part of the work are appropriately addressed. Correspondence concerning this article should be addressed to Minji Jeon.

Introduction

Computer Science (CS) education has garnered significant attention in recent years (Google LLC. & Gallup Inc., [15]). This trend is partly due to the digital industry's growing influence on the national economy, accounting for 9% of US GDP (Nicholson, [32]). Consequently, there is an increased demand for computing positions, highlighting the need to strengthen the CS workforce pipeline (U.S. Bureau of Labor Statistics, [43]). However, the importance of CS education extends beyond preparing CS professionals, because we need to cultivate fully functional citizens in a digital society (Guzdial, [18]; Vogel et al., [45]). Since digital technology increasingly integrates into our daily lives, it fundamentally changes how we perceive the world and ourselves. To educate digitally literate citizens, industry leaders, politicians, educators, and advocacy groups are making efforts to expand CS education (e.g., Microsoft, Apple, Computer Science Teachers Association, CSforALL). Due to these multifaceted endeavors, individuals outside the STEM field are gaining more opportunities to engage with CS through K-12 curricula and community outreach programs supported by nonprofit organizations or higher education (Code.org et al., [8]).

Keeping up with the rise of general CS education, making an effective and engaging CS learning environment for novices has received a substantial interest (see Kim et al., [22]; Kwon, [24]). Programming, representing the disciplinary formalism of CS, is considered a core practice within CS education, placing it at the forefront of the curriculum (Krishnamurthi & Fisler, [23]). It is widely acknowledged that programming presents a notable challenge for novices (Robins, [36]). Teaching programming also faces difficulties, as pedagogical principles for CS education remain a topic of ongoing debate (see Vihavainen et al., [44]). As the field is beginning to broaden the knowledge base, we lack consensus on how to effectively teach programming to novices. Various approaches have been suggested, including unplugged activities, pseudo-codes, robots, and block-based programming (Luxton-Reilly et al., [27]). This study focuses on block-based programming, which has become a popular method for introducing programming to novices, examining how different programming environments support the development of computational thinking and programming proficiency.

Block-based Programming and Text-based Programming

Block-based programming (BBP) is recommended for introductory CS classes, particularly for young learners to enhance understanding of CT concepts, CT practice, and to boost motivations for further CS learning (Meerbaum-Salant et al., [31]; Sáez-López et al., [37]). BBP languages, such as Alice, App Inventor, and Scratch, offer a more accessible representational system to novice programmers (Weintrop & Wilensky, [48]). Scratch is one of the most popular BBP languages for beginners, as it has intuitive user interfaces that allow learners to easily grasp the meanings of codes and the rules for combining them (Maloney et al., [29]). BBP has proven effective for novices in developing computational identity, viewing oneself as an active part of computational community capable of understanding and creating computational artifacts (Tissenbaum et al., [41]), sustaining motivation and interests, and facilitating quicker processing (Price & Barnes, [35]).

As BBP languages have gained popularity in the introductory CS learning environment, there is an increasing interest in addressing the next step toward text-based programming (TBP) (Armoni et al., [3]; Tshukudu & Cutts, [42]). The progression from early programming experiences in BBP to more sophisticated and authentic practices in TBP is a critical issue in CS education. Despite the advantages of BBP for instruction, its role in supporting the transition to TBP remains uncertain. In fact, research has shown that students with prior BBP experience do not necessarily outperform their peers in TBP environments (Armoni et al., [3]; Grover & Pea, [16]; Pea & Kurland, [33]; Xu et al., [51]). For instance, Weintrop and Wilensky ([46]) conducted a quasi-experimental classroom study where novices engaged with either BBP or TBP for five weeks before moving to a TBP language, Java, for an additional 10 weeks. They observed that while students initially made significant gains with BBP, these improvements did not continue in the subsequent Java training (Weintrop & Wilensky, [46]). This lack of sustained improvement might be due, as Weintrop and Wilensky ([46]) acknowledged, to the instructional design not fully leveraging the structural and feature similarities between BBP and Java, leaving students unsupported in recognizing the parallels and differences between the two programming environments.

Parallel Instruction

One approach to solve this problem involves integrating novices' learning trajectories in BBP and TBP, a strategy that is not yet well-documented in the CS education literature. Traditionally, multiple programming languages are taught sequentially, focusing on one language at a time. In contrast, parallel instruction organizes learning components around CS concepts, with relevant programming features explored across both languages simultaneously. This method is termed parallel instruction because it teaches different languages side-by-side, structured around pertinent CT concepts.

Understanding and transferring unfamiliar or complex concepts are enhanced when learners encounter diverse contexts in which to apply their acquired knowledge (Brown et al., [7]; Engle et al., [11]). Thus, our interest lies in how novice programmers' practices are shaped by parallel instruction that incorporates two languages of different modalities, BBP and TBP. To explore this, we designed an introductory CS curriculum featuring parallel instruction, allowing learners to acquire specific CS concepts while engaging in computational problem-solving with both languages. This study aims to investigate how learners' computational practices are developed and evolved through the parallel instruction of BBP and TBP.

Computational Thinking Framework

To address the research purpose outlined above, we adopted the Computational Thinking Framework proposed by Brennan and Resnick ([6]) as our theoretical basis for analysis. Computational thinking (CT) is defined as a computer scientist's way of thinking, encompassing thought processes such as abstraction, pattern recognition, decomposition, parameterization, algorithmic design, and more (Wing, [49], [50]). Brennan and Resnick ([6]) established the CT framework and operationalized the three dimensions of CT: concepts, practices, and perspectives. This framework has been extensively investigated across various subjects (e.g., Weintrop et al., [47]), and age levels (e.g., Grover et al., [17]; Kafai & Burke, [20]). CT concepts are fundamental "syntactic, semantic, schematic knowledge" that programmers employ in their practice (Lye & Koh, [28], p. 52). CT practices involve the strategic design processes for creating artifacts or solving problems (Brennan & Resnick, [6]; Lye & Koh, [28]). Lastly, CT perspectives are the dispositions of program designers that represent how they perceive or evaluate themselves, their relationship with others, and their interaction with technologies. (Brennan & Resnick, [6]).

Grounded in this framework, we designed a curriculum featuring parallel instruction, where learners were taught one or two CT concepts and then applied them to tackle computational problems using both BBP and TBP. The study aims to investigate novices' CT concepts and CT practices displayed in parallel instruction and to identify progress and challenges learners encountered in their computational problem-solving. By examining how juxtaposing BBP and TBP affects novices CT practices, this paper aims to provide practical insights, including the implications of, and feasible instructional strategies for, parallel instruction. Specifically, this paper addresses the following research questions.

Research Questions

RQ1. What are the synergistic effects of parallel instruction of BBP and TBP on learners' CT practice?

RQ2. How do learners' CT practices evolve when encountering unique features in TBP?

RQ3. What are the learners' CT practices applied in computational problem-solving across programming languages?

Method

Participants

The participants were eight pre-service teachers, consisting of seven female students and one male student. None of the students specialized in the field of STEM. These students were enrolled in a face-to-face 16-week course required for obtaining a computer educator license in addition to the elementary and secondary education license. Prior to this class, the students had become familiar with the Scratch interface and had acquired basic CT concepts in a prerequisite course.

Contexts

In the class, students were taught CT concepts such as variables, operators, functions, conditionals, and loops through lectures, followed by coding practice sessions in both Scratch and Python to apply these concepts (see Table 1). For the first nine weeks, the CT lessons were structured to cover one or two CT concepts each week. Each week, students were asked to apply a specific CT concept to solve computational problems using Scratch and Python, respectively. For example, in the sixth week, students were taught the concept of loops through a lecture and then asked to make a countdown timer in both languages. They developed a timer app using repeat and if blocks in Scratch, and while and break statements in Python. During the nine weeks of parallel instruction, students created two midterm projects, one in Scratch and one in Python. The remainder of the curriculum focused solely on Python. Although not included in the study, students completed additional assignments, such as take-home quizzes and computational problem-solving tasks using pseudo-codes, in which they were asked to develop their programs in Scratch or Python to reinforce the principal construct of the week. While completing weekly assignments, students wrote reflection notes explaining how their program worked, what they thought went well or not during the developmental process, and any areas of improvement.

Table 1 The Parallel Curriculum of Scratch and Python

<table frame="hsides" rules="groups"><thead><tr><th align="left"><p>Weeks</p></th><th align="left"><p>CT Concepts</p></th><th align="left"><p>Scratch Keywords</p></th><th align="left"><p>Python Keywords</p></th><th align="left"><p>Quiz</p></th><th align="left"><p>Assignments</p></th></tr></thead><tbody><tr><td align="left"><p>1</p></td><td align="left"><p>Orientation</p></td><td align="left"><p>Setting up workspace</p></td><td align="left" /><td align="left" /><td align="left" /></tr><tr><td align="left"><p>2</p></td><td align="left"><p>Data representation</p></td><td align="left"><p>variables, set, change</p></td><td align="left"><p>Assignment operators</p></td><td align="left"><p>In-class quiz 1</p><p>Take-home quiz 1</p><p>reflection note*</p></td><td align="left" /></tr><tr><td align="left"><p>3</p></td><td align="left"><p>Function 1</p></td><td align="left"><p>my-block</p></td><td align="left"><p>def, return</p></td><td align="left"><p>In-class quiz 2</p><p>Take-home quiz 2</p><p>reflection note*</p></td><td align="left"><p>Problem-solving 1</p></td></tr><tr><td align="left"><p>5</p></td><td align="left"><p>Conditional & Operators</p></td><td align="left"><p>if, if-else</p><p>nested if</p></td><td align="left"><p>if-else</p></td><td align="left"><p>In-class quiz 3</p><p>Take-home quiz 3</p><p>reflection note*</p></td><td align="left"><p>Problem-solving 2</p></td></tr><tr><td align="left"><p>6</p></td><td align="left"><p>Loops</p></td><td align="left"><p>repeat, forever</p></td><td align="left"><p>while-loop, break,</p><p>for-loops, list</p></td><td align="left"><p>In-class quiz 4</p><p>Take-home quiz 4</p><p>reflection note*</p></td><td align="left"><p>Problem-solving 3</p></td></tr><tr><td align="left"><p>7</p></td><td align="left"><p>Algorithm 1: search, sorts</p></td><td align="left" /><td align="left" /><td align="left"><p>In-class quiz 5</p><p>Take-home quiz 5</p><p>reflection note*</p></td><td align="left"><p>Problem-solving 4</p></td></tr><tr><td align="left"><p>8</p></td><td align="left"><p>Function 2: arguments</p></td><td align="left"><p>my-block</p></td><td align="left"><p>def with arguments</p></td><td align="left"><p>In-class quiz 6</p><p>Take-home quiz 6</p><p>reflection note*</p></td><td align="left"><p>Scratch project*</p><p>reflection note*</p></td></tr><tr><td align="left"><p>9</p></td><td align="left"><p>Function 3: recursion</p></td><td align="left"><p>my-block</p></td><td align="left"><p>def, return, global, recursion</p></td><td align="left"><p>In-class quiz 7</p></td><td align="left"><p>Problem-solving 5</p></td></tr><tr><td align="left"><p>11</p></td><td align="left"><p>Module,</p><p>Strings,</p><p>List Data</p></td><td align="left" /><td align="left"><p>import, strings, list, tuple, dictionary</p></td><td align="left"><p>In-class quiz 8</p><p>Take-home quiz 7</p><p>reflection note*</p></td><td align="left"><p>Problem-solving 6</p></td></tr><tr><td align="left"><p>12</p></td><td align="left"><p>For-Loop with list</p></td><td align="left" /><td align="left"><p>for-loop, list</p></td><td align="left"><p>In-class quiz 9</p></td><td align="left"><p>Python project*</p><p>reflection note*</p></td></tr><tr><td align="left"><p>13</p></td><td align="left"><p>Problem-Solving</p></td><td align="left" /><td align="left" /><td align="left"><p>Take-home quiz 8</p></td><td align="left" /></tr><tr><td align="left"><p>14</p></td><td align="left"><p>Module</p></td><td align="left" /><td align="left"><p>def, import</p></td><td align="left"><p>Take-home quiz 9</p></td><td align="left" /></tr><tr><td align="left"><p>15</p></td><td align="left"><p>Class</p></td><td align="left" /><td align="left"><p>class, def</p></td><td align="left" /><td align="left"><p>Final Project</p></td></tr></tbody></table>

* Included in the dataset for analysis in the current study A week of Thanksgiving is excluded from the table

Data Collection

For course assignments, students created two programs each in Scratch and Python. The theme and purpose of each program were at the students' discretion. In total, eight Scratch and eight Python programs were collected and analyzed. Additionally, students' reflection notes were gathered to document their perceptions of their learning experience, progress, and challenges. Student names were replaced with pseudonyms to ensure anonymity during analysis. The analysis focused on investigating the students' understanding of CT concepts and practice as demonstrated in their self -authored programs developed in both languages.

Data Analysis

The researchers examined 16 student-developed programs focusing on the CT concepts dealt in the class. Learners' understanding of CT concepts and proficiency of CT practice demonstrated in the Scratch and Python programs were systematically analyzed following the analytic framework suggested by Braun and Clarke ([5]).

The researchers first read through the student-developed codes concentrating on pertinent and significant anecdotes emerged in learners' CT practice. These patterns incorporated strategies or errors that the students frequently committed in their codes. The researchers revisited the programs again to jot down what they noticed. This process was iterated two more times on one-month interval at least. Sequentially, the accumulated memos were separated by programming languages and arranged in respective tabular forms whose columns represented CT concepts such as functions and loops and each row indicated a student's work. The students' reflection notes were added to the tables separated by concepts.

According to individual concepts, the themes were constructed by synthesizing patterns that are commonly shared in multiple students' works or showcase novices' developmental phases. At this stage, the meanings of each theme were vaguely generated. The themes and tentative definitions were reviewed between researchers to make sure that they sufficiently represent the students' CT practice. The researchers shared what had been highlighted in individual analyses and discussed to address divergent opinions.

The researchers then reanalyzed the students' programs focusing on the established themes and gathered the final examples that would fall onto each theme. Detailed descriptions of each theme were given during this process. By means of iterative analytical process, we confirmed and solidified our findings and made our interpretations more consistent (Slevin & Sines, [38]). Finally, one or two exemplary anecdotes that the researchers think most transferable and best represent the phenomena at hand were chosen for further illustrations.

Findings

The analysis findings will be presented in three parts. First, we will discuss the learners' CT practices related to specific CT concepts that improved during the parallel instruction of BBP and TBP. Second, we observed that while students adapted well to some unique features of TBP, they also encountered difficulties with certain additional features. Lastly, we will describe the students' CT practices in the context of general computational problem-solving. This study specifically elaborates on the characteristics of novices' CT practice across different CT concepts and programming environments.

Synergistic Effects in the Parallel Instruction of BBP and TBP on CT Practice

Learning Scratch and Python side-by-side, the students' CT practices showed progress with regard to certain CT concepts. Specifically, we found that learners improved their skills in dealing with operators, conditional executions, functions, and variables.

Operators

All students incorporated various operators such as arithmetic, assignment, and comparison operators. Initially, they experienced more difficulty with operators in Scratch than in Python. Some complained that using operators in Scratch was more cumbersome. For example, Bella commented in her reflection note, "I could not figure out how to add more than four of the variables using the operation pieces. That is something I think would be easier or more efficient to write in actual coding language, rather than a block-based system."

Many students struggled at forming a non-strict inequality condition in Scratch (e.g., "greater (less) than or equal to"). While this is straightforward in Python, which uses a single operator (" > = "), Scratch requires combining two statements: "greater than (>)" and "equal to (=)" with a logical operator (and) (see Fig. 1). Students were disappointed to discover that they had to combine three blocks to achieve this.

Graph: Fig. 1 Non-strict Inequality Condition in Scratch

However, their perceived inconveniences with operators were resolved once they learned how to combine multiple conditions in Scratch. They began to add more operators and appreciated their advantages. Shiloh noted, "I finally figured out how to join ... operations so I was able to say multiple things at once." Layla wrote "I really liked being able to use the 'and' operator when two statements are true. I used this button in the if-else statements, for the first time, and it cut down a few lines of code for me." As their comments indicate, mastering operators contributed to improving their practice with conditional executions.

Though combining three codes and duplicating the reference object might seem undesirable and inefficient, the structure shown in the BBP environment has its merits, aligning with their practice in TBP. Novice programmers are likely to produce syntax errors when they are manipulating operators in Boolean contexts in TBP. For example, Caroline attempted to maintain two strings as possible answers, using the "or" operator. However, as shown in Fig. 2, there was no object to compare the second expression against (i.e., A = B or C). In this context, the condition is always evaluated as true regardless of user input. She should have added the referent to be evaluated against as shown in Fig. 3 (i.e., A = B or A = C). By practicing operators in Scratch, most students became familiar with forming composite conditions. This may explain why so few syntax errors were observed with operators in this study.

Graph: Fig. 2 Misuse of Operators with a Referent Omitted (Caroline)

Graph: Fig. 3 Correct Use of Operators with a Referent Added

Conditional Execution

The syntactic similarity in both languages helped learners understand and employ conditional executions. The students incorporated conditions and made their programs execute more efficiently. In both languages, the students were able to enumerate all possibilities and separate branches accordingly. For instance, they logically constructed if-else clauses, which could be used in the decision-making process multiple times (e.g., Fig. 4).

Graph: Fig. 4 Exhaustive and Mutually Exclusive Conditions in an If-else Clause

When taught about conditional statements, the students started by practicing simple conditional constructs like if–then and subsequently advanced to more complex constructs such as if-else-then and then nested if-else. The BBP environment visualizes the structure of conditionals, assisting learners in comprehending and generating complex conditionals. The students gained more confidence in applying conditional constructs in their programs as they practiced more with Scratch. Caroline remarked, "I was able to include three separate conditions in a single operator for each if-else statement, which made the program much more efficient and ultimately reduced the likelihood for error" (see Fig. 5). In the following week, she said "... [the nested if-else statements] are smaller and more efficient than the ones I created last week because I removed the superfluous conditions."

Graph: Fig. 5 Complex Conditionals (If-else-then and Nested If)

Functions with Parameters

In Scratch, my blocks are used to keep a set of procedures defined by a user, corresponding to functions in other languages. In their Scratch programs, all students developed at least one function, and some included parameters. For example, Hannah defined three my blocks to draw a square, a triangle, and a circle (Fig. 6). Despite having different sizes and locations, figures of the same shape share codes to draw a contour. These functions are called several times to collectively draw a house. Functions in BBP have users drag a parameter block from the defining statement. This makes users realize that the arguments used in the body of procedures inherently come from the set parameters, which are viable to vary and make changes in the outcome.

Graph: Fig. 6 Scratch: Functions with Parameters Used to Draw Shapes of Different Sizes and Locations (Hannah)

After recognizing the roles of parameters in Scratch, the students didn't appear to have trouble defining functions with parameters in Python. For instance, Bella defined a function, "run_score" with three parameters to output the corresponding result to the score and print the result along with the values entered (Fig. 7). Drawing on parameters, the students managed to pass different values as arguments in a function. The students took advantage of parameters to abstract the commonly shared procedures into functions and used functions in expanded circumstances.

Graph: Fig. 7 Python: A Function with Parameters (Bella)

Initially, they regarded functions as somewhat unnecessary, but with parameters, they came to see the virtue of using functions with parameters. "I am wondering about how I could combine the three functions for the questions into one function and use multiple arguments. I think that making this change would ultimately result in a program that is more efficient and less susceptible to error," stated Caroline.

Variables

Beyond the basic use of variables, some students evolved their CT practice with variables during the parallel instruction. Though variables in Scratch are mostly used for holding numeric values, we observed some extended uses of variables in Scratch. Inspired by versatile uses of variables in Python, learners applied these strategies to Scratch for controlling execution flows and keeping user inputs.

Variables to Control Execution Flows

The students' advanced CT practice with variables was found in their use of Boolean variables as flags. Flags are logical or Boolean type variables that can take only two values, 0 or 1, True or False (Downey, [10]). A flag variable is an indicator that tells whether a condition of interest is met and whether a set of actions will be followed as a consequence. Flag variables are often employed for conditional loops in Python that either continue or break iterations. On the other hand, flag variables are rarely used in Scratch. In fact, novice programmers usually make variables to represent concrete objects such as counting up scores or the number of Sprites (Fig. 8). Without any requirement to use flags, however, half of the students incorporated flag variables in their Scratch programs to control loops. For example, Bella created two flag variables, and one of her flags, "find Sebastian" indicates whether a specific Sprite has been found (Fig. 9). This variable is initially set to 0, and the nested blocks used to play music are repeated as long as it stays at 0. Once the target is found, "find Sebastian" returns 1 and breaks the repeat-until loop.

Graph: Fig. 8 Typical Use of Variables in Scratch: Representing Concrete Objects

Graph: Fig. 9 Variables Used as Flags in Scratch (Bella)

In her Scratch scripts, the variables are combined with a repeat-until block to compose a loop construct that corresponds to a while-loop in Python. In fact, Bella frequently used flags for while-loops in her Python program as well (Fig. 10). The entire flow of her program is controlled by a while-loop, and the loop is mediated by a flag called "play" that moves the game forward when it is 0 and ends the game when it is 1.

Graph: Fig. 10 Variables Used as Flags in Python (Bella)

Bella's use of flag variables departs from the conventional practice of Scratch beginners, who mostly use variables for counting denumerable objects. She applied a flag variable to denote an abstract logical value in both Scratch and Python programs. Similarly, another five students used flags in regulating loops. Based on our observations, we speculate that the presence of flags in the students' Scratch programs is attributable to their programming experience in Python. Applying flags is a useful technique for developers, as loops control the execution flow of programs. Our findings suggest that learners developed a general CT ability unbound to specifics of individual languages as they were simultaneously engaged with BBP and TBP.

Variables to Maintain User Inputs

The students demonstrated advanced CT practice in handling user inputs with variables. Five out of eight Scratch programs included a component that requests user inputs using ask blocks and sets variables to store the responses. This practice is analogous to input functions in Python that prompt a message and take in an input. While it is common in Python to set variables to the entered response as shown in Fig. 11, this is not typically the case in Scratch, especially for novices. Scratch offers a built-in answer block, which does not require the use of more generic variable blocks. However, we found from the Scratch scripts that the learners chose to set variables to user inputs even when they could have simply used the built-in ask/answer blocks. For example, Michael asked two different questions and set two variables for each answer (Fig. 12). He maintained individual values separately and used them for making decisions in the conditional statement.

Graph: Fig. 11 Setting Variables to User Inputs in Python

Graph: Fig. 12 Setting Variables to User Inputs in Scratch 1 (Michael)

It appears that the learners extended a strategy acquired in Python to Scratch. While programming in Python, the students practiced manipulating multiple variables more elaborately, considering varied places they would be used. The hint of transfer here is reified by some students' scripts that save user inputs to variables even when it is not strictly necessary. For instance, Jocelyn set a variable to an answer even if she used ask/answer blocks only once, indicating just one input (Fig. 13).

Graph: Fig. 13 Setting Variables to User Inputs in Scratch 2 (Jocelyn)

Lesson Learned: Maximizing Synergistic Effects Through Shared Features in BBP and TBP

The students demonstrated advanced CT practice influenced by both languages, particularly with operators, conditional statements, functions involving parameters, and variables. These successful CT practices were mostly observed in areas where Scratch and Python share similar features or structures. Transfer is enhanced when performances are built upon similar structures, and it is further facilitated when learners notice comparable features (Gick & Holyoak, [13]; Holyoak & Koh, [19]). To amplify the synergistic effect of parallel or sequential instruction, it is suggested to remind learners of the shared features or structure between languages used in similar tasks. By being conscious of these resemblances, we expect learners will develop a more elaborate CT practice that is applicable to broader contexts and will be able to readily move forward with other programming environments.

Progress & Challenges of CT Practice in Dealing with Unique Features in TBP

Due to its unique, advanced features, Python affords and requires more sophisticated CT practice than Scratch. When the students were challenged with the additional features in TBP, the learners' CT practice adapted to these new additional features. Yet, there were certain areas where the students struggled and did not perform satisfactory practices in TBP.

Successful CT Practice with Unique TBP Features

The students sufficiently accommodated some advanced features of TBP and displayed refined CT practices with the features unique to Python and absent in Scratch. Specifically, the students demonstrated advanced CT practice in implementing distinct data types and case sensitivity in Python.

Data Types

While Scratch is flexible with data types, one must identify the data types such as numerics, strings, and lists in Python. Therefore, the students learned to recognize the various data types and convert them when needed. For example, Shiloh altered a numeric data named "price" to a string by str function (Fig. 14). The students were also able to manipulate list objects with list methods such as list.append or list.remove. Olivia designated lists of possible responses from the users and added them as elements in the set using "append" method (Fig. 15).

Graph: Fig. 14 Numeric and String Data Types in Python (Shiloh)

Graph: Fig. 15 List Data Types in Python (Olivia)

Case Sensitivity

It is important to highlight case sensitivity when learners are transitioned from Scratch to Python, as Scratch doesn't distinguish cases. Identifying upper- and lower-case letters might be a barrier to interacting with a user input in Python. Such constraints, however, encourage students to consider multiple solutions to similar problems. In the following example, two students applied different techniques to achieve the same task for a quiz game in Python. Both students designed methods to evaluate user responses against a set of predetermined answers and accept any answers spelled out right regardless of capitalizations. To do this, Layla attached a string method to the entry as in "AnswerTwo.lower()" (Fig. 16). On the other hand, Caroline chose to use a logical operator, or to accommodate possible answers (Fig. 17).

Graph: Fig. 16 A String Method to Deal with Case Sensitivity in Python (Layla)

Graph: Fig. 17 An Operator to Deal with Case Sensitivity in Python (Caroline)

These findings revealed that the learners adapted to added features of a new programming environment by devising strategies for case sensitivity in Python. It also implies that these complications provide students with learning opportunities to comprehend how various methods and techniques operate. Parallel instruction should leverage the environmental differences and utilize them as authentic sources for conditions required for problem-solving.

Underdeveloped CT Practice with Unique TBP Features

Meanwhile, the students had a hard time getting adjusted to some of the additional features in TBP. Particularly, managing the scope of variables and distinguishing different loops in Python appeared to be challenging to novices.

Variable's Scope

When defined inside a function, a variable is local, and when defined outside a function, it is a global variable. In Scratch, the scope of variables is not explicit, and most variables are treated globally. On the other hand, the scopes of variables are saliently discriminated in Python where variables created in a function are local by default. Therefore, a keyword, global, is necessary to consistently update a value of a local variable in a way that it lives outside of a function and affects the entire program. Learners tend to get confused with the different scopes of variables which are likely to induce errors in their programs. Most of the students in the class successfully used a global method to change the scope of variables placed inside a function. However, a few students found it challenging to modify a variable's scope.

For instance, in Layla's quiz game in Python, she made a function named "Question" and added a variable "points" inside to track points scored. Her attempt to update the variable (e.g., "points + = 10") went in vain as these commands are not effective without a global method (Fig. 18). Another student, Bella, mentioned that "[she and her colleague kept] forgetting to make the variables global within the function". As learners did not experience the concept of scopes, they needed to be encouraged to discern variable's scopes and keep in mind declaring "global" keyword for local variables to be accessed outside a function.

Graph: Fig. 18 Variables Missing a Global Statement (Layla)

Another problem of scopes arose from superfluous uses of global methods. In Shiloh's cash register application, global statements for variables were used redundantly without changing values. In Fig. 19, the prices for a dish were assigned outside a function. As these prices are not modified to different values within the function, there was no need to declare the variables global. Such redundant codes were observed in a few other scripts, where global methods were used excessively without much thought. This indicated that the students' understanding of variable scopes was not fully developed yet. Learners should be encouraged to consider why they are using specific methods and to eliminate any unnecessary codes. As the learners were used to handling variables in a simple manner with Scratch, they were not fully adjusted to distinguishing variable scopes in Python.

Graph: Fig. 19 Superfluous Uses of Global Statements (Shiloh)

Different Loops in Python

A loop repeats a set of instructions until a certain condition is met. Most students didn't seem to have difficulty grasping the concept of loops and applying them in Scratch. However, using loops in Python appeared to be more challenging since the conditions embedded in loops differ from those in Scratch. Whereas Scratch executes the instructions inside a loop when the condition remains false, Python does it when the condition remains true. This difference is related to the semantics of the commonly used codes for loop: repeat-until blocks in Scratch and while-loop in Python. The students were confused about the way conditions are stated, which was evident in some of their scripts.

In addition, there were a few students who were unable to distinguish the purpose and usage of a for-loop and a while-loop. Vivian set a variable "i" to 0 before the for-loop and increased it by 1 after each iteration inside the loop (Fig. 20). Given "i" is not necessary in this case, she seems to have confused it with while-loops. While-loops usually accompany indexing variables to evaluate whether a condition is true. These indexing variables are incremented after a set of instructions is completed to prevent the sequences within a loop from being repeated more than needed. In contrast, it is not required in for-loops to set an indexing variable before the loop or increment them at the end of instructions. Therefore, Vivian's variable, "i" was not necessary and didn't impact the rest of her program.

Graph: Fig. 20 Confusion of For-loops and While-loops (Vivian)

Lessons Learned: Navigating Challenges with Unique Features in TBP

We found that by presenting TBP along with BBP, the students successfully grasped additional programming features such as various data types and case sensitivity. However, it was also noted that the scope of variables, and while- and for-loops, were particularly challenging to the students when they engaged in programming with Python. As these features are lacking in BBP, more attention is required when novice programmers encounter them in TBP. When learners come across inconsistent features between BBP and TBP from a parallel or even sequential instruction, it is recommended to direct their attention to those differences so that they can notice and reflect on them in their CT practice. Further, it is important to encourage learners to consider how they can extrapolate pertinent strategies or techniques from past CT practice with a more familiar language to navigate the complications resulting from these differences.

CT Practices Applied in Computational Problem-Solving

So far, we have explained the students' CT practice in terms of specific CT concepts and features of programming environments. In this section, we will look at the students' CT practices through the lens of computational problem-solving. The implications of their CT practices will be discussed in a broader sense, focusing on their CT practice with controlling executions and abstracting procedures.

Gradual Improvement of CT Practice in Controlling Flows

To control the overall execution flows in their programs, the students used different concepts and strategies. We speculate that a novice programmer's ability to control flow in Scratch develops in the order as: time-based controls, message-passing controls, and condition-based controls. Time-based controls are implemented with wait blocks. Message-passing is executed by broadcast and receive blocks. Finally, condition-based blocks are divided into conditional execution with if–then or if-else-then blocks, and conditional repetitions with repeat-until blocks.

Initially, the students predominantly used time-based controls, referencing how many seconds it takes before a particular action happens. After realizing it is inefficient to calculate the duration of a certain sequence, they began using more broadcast and receive pairs (message-passing controls). Lastly, as they became more acquainted with conditional statements, they used more if–then and repeat-until controls (condition-based controls).

The students were conscious of this progression in their strategies for manipulating control flows. This was evident in their reflection notes: Layla stated "... last week, I used to have my Sprites rely on timers to begin their action/prompting questions. I would add one step at a time, count the seconds, and it was a long process. Now, I use the broadcast button/control ... I am able to tell my Sprite not to begin a specific action until another one has finished. This has saved me a lot of time ..." Growing in their tendency to use more advanced controls, some students explicitly mentioned that message-passing is inferior to using conditionals or loops. Michael wrote, "... I felt that I relied heavily on broadcasting to force things to happen, ... it would have been more efficient to have a 'wait until hear whistle' control."

The condition-based controls are divided into conditional repetitions (e.g., repeat-until) and conditional executions (e.g., if–then, if-else-then, nested if–then). Conditional repetitions, rather than simple repetitions such as forever and repeat blocks, are considered to demonstrate a higher level of CT practice (i.e., "complex loops" in Basu, [4]). We observed that the students who adopted more conditional repetitions tended to apply fewer conditional executions. Conversely, students who predominantly used conditional executions employed fewer conditional repetitions. This is reasonable because both conditional repetitions and conditional executions are used for branching or directing to different instructions. Holding similar roles in controlling execution flows, conditional repetitions and conditional executions were often substituted for each other in the students' scripts.

By leveraging these proposed phases, novices develop their CT practice in controlling flows, making it possible to gauge where a learner's current level of CT practice is situated. This diagnosis can then be used to provide tailored scaffolding for metacognitive strategies in computational problem-solving. Instruction should be designed to facilitate learners in moving forward with implementing higher-level control in their programs. One recommendation is to encourage learners to explore diverse strategies to solve a particular computational problem. This could be achieved by peer interactions, such as self-explanations or learning-by-example (e.g., Lin et al., [25]; Liu et al., [26]). By considering alternative approaches, learners can compare and evaluate strategies, which will enhance their abilities to apply them in their CT practice.

Abstracting and Modularizing

Abstractions and modularizations make computational executions more efficient and less complex by encapsulating procedures for reuse. Brennan and Resnick ([6]) defined abstracting and modularizing as combining smaller pieces to develop a larger entity, highlighting them as key CT practices. Statter and Armoni ([39]) further claimed that abstraction skills are pivotal for the rest of the CT practices and fundamental goals in introductory CS courses. However, researchers have reported that students experience substantial challenges in abstracting (Armoni, [2]; Zehetmeier et al., [52]) and modularizing (Piteira & Costa, [34]). Consistent with these previous findings, we observed that the learners had difficulty applying abstractions in their programs. Specifically, the students demonstrated less efficient CT practice with their use of loops and functions.

Functions (my blocks in Scratch) are useful tools for abstractions and modularizations. There are mainly two purposes of functions in programming: 1) reducing the length of scripts by creating a separate module that can be called repetitively across the program, and 2) making the structure of a program more apparent and logical by compartmentalizing meaningful segments of procedures. However, it was observed from both languages that learners seem to be unaware of why they were using functions in their program.

Though employing functions in their programs, some of the students did not reuse them more than once. Out of eight Scratch programs, six included functions, but only three used the defined functions more than once. Further, there was only one student who defined more than one function and used them multiple times. In Python, seven students created functions, but only four of them reused the defined functions.

Although these functions did not reduce the size of the programs, a few students enhanced the readability of their code by incorporating functions. Figures 21 and 22 illustrate functions defined and used only once in Scratch and Python, respectively. These functions help readers understand the overall structure of the program more easily and grasp how individual chunks are organized. By using descriptive names (e.g., Tell Joke, Tell Second Joke; intro, middle, last), readers can quickly recognize their roles within the program. This structuring also aids programmers themselves, as legible scripts facilitate the debugging process by making it easier locate error-prone codes or remove dead code (Aivaloglou & Hermans, [1]).

Graph: Fig. 21 Functions Used Once but Enhancing Readability in Scratch

Graph: Fig. 22 Functions Used Once but Enhancing Readability in Python

However, some students did not take advantage of functions, resulting in programs that were neither more efficient nor systematically organized. This unsatisfactory practice can be attributed to two main reasons. Firstly, the target procedures might have been too simple to warrant abstraction, which would not be an issue in an authentic programming situation. Secondly, students may have modularized incompatible sets of instructions rather than recurring sets shared across the program (Fig. 23). This issue relates to students' abilities in recognizing patterns. Pattern recognition, a key component of CT practice, involves identifying repetitions, patterns, or regular entities from data and processes (Dong et al., [9]; Grover & Pea, [16]). Pattern recognition is closely associated with abstraction skills, as procedures to be abstracted need to be observed and identified first.

Graph: Fig. 23 Less Efficient Modularization for Defining Functions in Python

Overall, in both languages, we identified numerous instances where learners' solutions could have been more efficient through the use of abstractions and modularizations. The students appeared confused about the concept of functions and how to apply them in practice. Jocelyn wrote in her reflection, "I feel like I went the long way somehow, as it felt like I put in way more work than needed ..." Similarly, Shiloh noted, "I don't know if the blocks I used actually benefited me or made things easier, or if I still added in extra steps anyway...I was still a little confused ... if it even made my project more efficient."

Based on their reflections, it is clear that helping students understand the roles of functions is essential to address these issues. Layla remarked, "At first, I could not understand the purpose of the my block, because I felt that I was able to complete the challenge ... without using the my block. However, I learned that using the function can actually make the program run smoother because there is less chance for error when the user defines a function for the computer to read ... the function overall makes creating codes simpler and more manageable."

The difficulties students faced in recognizing the value of abstraction might have led to inefficiency in their CT practice. At this stage of understanding, it is crucial for novice programmers to notice the benefits of applying abstraction and modularization in developing programs. Additionally, as pattern recognition is a key aspect of abstraction, novice programmers should be trained to distinguish what's fixed and what's changing, identify recurring patterns, and encapsulate these patterns within reusable modules. Enhancing pattern recognition can be effectively paired with teaching parameterization skills discussed earlier.

In addition, it is worth mentioning that students are more likely to enhance abstractive thinking when encouraged to devise a plan rather than relying on a trial-and-error approach. Downey ([10]) identified two approaches to programming development. One approach, known as "prototype and patch," involves creating an elementary prototype and cumulatively modifying it by correcting errors along the way. Although this method may seem convenient at first, it has limitations, often resulting in error-prone and overly complex code (Downey, [10]). In contrast, an alternative approach, "designed development," tackles a computational problem with systematic insights, leading to more concise, consistent, reliable, and readable code (Downey, [10]).

It is recommended that learners arrange ideas by abstraction first, establishing a solid foundation for problem-solving. One of the typical mistakes that novices often make is moving too quickly to the development phase before thoroughly thinking through the logic for computational problem-solving (Mazlan & Othman, [30]). This can raise concern about learners' inefficient CT practice, lacking in abstracting and modularizing skills. Hasty implementation or rushing into coding can deprive novices of opportunities to analyze the specifications of a problem and structure complex ideas into a more legitimate, economical representation (Ginat, [14]). Therefore, it is suggested to teach learners how to engage in abstractive thinking and motivate them to identify the qualifications of a problem. Instructors need to guide learners to prepare the logic or algorithm beforehand, rather than patching up while writing and testing codes. These practices could strengthen learners' CT practice in developing more efficient and less complex procedures.

Discussion

Engaged in programming practice across languages, the students explored both consistent and inconsistent structures between BBP and TBP, acquiring strategies that could be shared in both environments. Differences across programming languages might lead to misconceptions but also afford transfer or further development in learners' understanding of CT concepts and techniques, enhancing their ability to apply them in actual coding.

Summary of the Findings

This study's analysis of student-authored programs with BBP and TBP revealed several key insights. First, there are indications that the learners' CT practices in respective programming environments positively influenced each other. These were most pronounced in areas where Scratch and Python share similarities, such as operators, conditional executions, functions, and variables. We assume that the structural similarity between the languages enabled learners to apply compatible CT practices. The analogous syntactic features aligned with CT concepts supported them in reflecting on their CT practice and adopting relatable techniques in each environment. These findings imply that involvement in parallel programming exerted a synergistic effect, elevating learners' performances in both languages.

Secondly, the parallel instruction incorporating a text-based language like Python fostered learners' engagement in more authentic and elaborate programming practices. The students developed their CT practice, particularly in dealing with different object types and case sensitivity. However, the students struggled with implementing the scope of variables and conditional repetitions when transitioning to Python. For these inconsistent features, it is recommended to direct learners' attention to distinct interfaces and guide them to develop new strategies to replace existing techniques that are incompatible with an unfamiliar environment.

Third, we highlighted CT practices that could be applied across languages, contributing to more efficient computational problem-solving. We proposed that novices' strategies to control flows in their Scratch programs tend to gradually evolve from time-based controls (wait), message-passing controls (broadcast, receive), to condition-based controls (if–then, if-else-then, while, repeat-until). Additionally, we observed practices in both languages that hampered novices' computational problem-solving. Overall, the students did not reach a desirable level of abstracting and modularizing skills. These findings support the notion that learners should be given opportunities to reflect on the benefits of abstraction. It is also crucial for learners to practice pattern recognition to identify similar structures and parameterize varying aspects.

Implications of the Parallel Instruction

The parallel instruction of BBP and TBP organized the learning components according to CT concepts, allowing for conceptual alignment of the two programming environments. This conceptual alignment led learners to compare programming features in Scratch and Python, noticing both common and disparate CT practices. Several affordances emerged in the context of programming learning.

First, it consolidated the commonalities of both languages, providing opportunities to practice CT concepts with multiple representational systems. This association constructed a related knowledge set rather than two separate entities. An integrated system of information decreases extraneous load and fosters schema acquisition compared to learning from temporally and spatially distributed sources (Sweller et al., [40]).

Secondly, the parallel instruction made explicit the distinct characteristics between the languages, directing learners' attention to specifics of each language. Structural alignment enhances the recognition of differences between disparate representations, making these differences more salient when associated with deeper common systems rather than shallow ones (Gentner & Gunn, [12]).

Lastly, parallel placement encourages learners to attend to underlying principles of CT concepts and CT practice when engaging in computational problem-solving. The parallel instruction supports learners in recalling their conceptual understandings and extending the CT practice they acquired from one platform to the other. This cross-application of CT practice could yield benefits in developing transferable knowledge structures (Kalyuga, [21]) and stimulating metacognitive processes for computational problem-solving.

Conclusion

In summary, this paper has provided insights into the learning trajectories for novices' CT practice and highlighted the opportunities and challenges of the parallel instruction in TBP and BBP. We have proposed potential instructional approaches or strategies to augment their synergistic effects and address the challenges posed by unfamiliar features. By presenting detailed descriptions of how two programming environments shaped learners' CT practice, this study bridges the gap between programming instruction of BBP and TBP. Furthermore, our findings indicate that novice programmers often lack skills in abstraction and modularization, regardless of the programming environment, emphasizing the need to focus on these areas in introductory programming stages.

Despite the exploratory evidence put forward by this study, these initial findings cannot be considered conclusive. More pedagogical and CS theoretical validations and empirical evidence are necessary. Future research should confirm the present findings using diverse methodologies, such as analyzing video recordings of novices' programming practice or conducting experimental studies to determine the presence or magnitude of the effects of the parallel instruction. Additionally, research should investigate learning gains from parallel instruction from more diversified perspectives (e.g., cognition, motivations, interactions) using their own conceptual and analytic frameworks. Lastly, future works should provide teaching and learning strategies for the practical application of the parallel instructional approach.

Funding

No funding was received for conducting this study.

Data Availability

Supporting data are not available due to the nature of the study.

Declarations

Conflicts of interest

The authors have no conflicts of interest to disclose.

Research involving human participants

The study involved human participants, and approval was obtained from Indiana University Institutional Review Board. The procedures used in this study adhere to the tenets of the Declaration of Helsinki.

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

References

1 Aivaloglou, E, & Hermans, F. (2016). How kids code and how we know: An exploratory study on the scratch repository. In Proceedings of the 2016 ACM conference on international computing education research (pp. 53–61). https://doi.org/10.1145/2960310.2960325

2 Armoni M. On teaching abstraction in CS to novices. Journal of Computers in Mathematics and Science Teaching. 2013; 32; 3: 265-284

3 Armoni M, Meerbaum-Salant O, Ben-Ari M. From Scratch to "real" programming. ACM Transactions on Computing Education. 2015; 14; 4: 1-15. 10.1145/2677087

4 Basu, S. (2019). Using rubrics integrating design and coding to assess middle school students' open-ended block-based programming projects. In Proceedings of the 50th ACM technical symposium on computer science education (pp. 1211–1217). https://doi.org/10.1145/3287324.3287412

5 Braun V, Clarke V. Using thematic analysis in psychology. Qualitative Research in Psychology. 2006; 3; 2: 77-101. 10.1191/1478088706qp063oa

6 Brennan, K, & Resnick, M. (2012). New frameworks for studying and assessing the development of computational thinking. In Proceedings of the 2012 annual meeting of the American Educational Research Association. AERA.

7 Brown JS, Collins A, Duguid P. Situated cognition and the culture of learning. Educational Researcher. 1989; 18; 1: 32-41. 10.3102/0013189x018001032

8 Code.org, CSTA, & ECEP Alliance. (2020). 2020 State of computer science education: illuminating disparities. https://code.org/assets/advocacy/stateofcs/2020_state_of_cs.pdf

9 Dong, Y, Catete, V, Jocius, R, Lytle, N, Barnes, T, Albert, J, Joshi, D, Robinson, R, & Andrews, A. (2019). PRADA: A practical model for integrating computational thinking in K-12 education. In Proceedings of the 50th ACM technical symposium on computer science education (pp. 906–912). https://doi.org/10.1145/3287324.3287431

Downey A. Think Python: How to think like a computer scientist. 20162; Green Tea Press

Engle RA, Lam DP, Meyer XS, Nix SE. How does expansive framing promote transfer? Several proposed explanations and a research agenda for investigating them. Educational Psychologist. 2012; 47; 3: 215-231. 10.1080/00461520.2012.695678

Gentner D, Gunn V. Structural alignment facilitates the noticing of differences. Memory & Cognition. 2001; 29: 565-577. 10.3758/BF03200458

Gick M, Holyoak KCormier SM, Hagman SD. Cognitive basis of knowledge transfer. Transfer of learning. 1987; Academic Press: 9-46. 10.1016/B978-0-12-188950-0.50008-4

Ginat, D. (2007). Hasty design, futile patching and the elaboration of rigor. In Proceedings of the 12th annual SIGCSE conference on Innovation and technology in computer science education (pp. 161–165). https://doi.org/10.1145/1268784.1268832

Google LLC. & Gallup Inc. (2020). Current Perspectives and Continuing Challenges in Computer Science Education in U.S. K-12 Schools. https://services.google.com/fh/files/misc/computer-science-education-in-us-k12schools-2020-report.pdf

Grover S, Pea R. Computational thinking in K–12: A review of the state of the field. Educational Researcher. 2013; 42; 1: 38-43. 10.3102/0013189X12463051

Grover S, Pea R, Cooper S. Designing for deeper learning in a blended computer science course for middle school students. Computer Science Education. 2015; 25; 2: 199-237. 10.1080/08993408.2015.1033142

Guzdial, M. (2019). Computing education as a foundation for 21st century literacy. In Proceedings of the 50th ACM technical symposium on computer science education (pp. 502–503). https://doi.org/10.1145/3287324.3290953

Holyoak KJ, Koh K. Surface and structural similarity in analogical transfer. Memory & Cognition. 1987; 15; 4: 332-340. 10.3758/BF03197035

Kafai YB, Burke Q. Constructionist gaming: Understanding the benefits of making games for learning. Educational Psychologist. 2015; 50; 4: 313-334. 10.1080/00461520.2015.1124022

Kalyuga S. Instructional designs for the development of transferable knowledge and skills: A cognitive load perspective. Computers in Human Behavior. 2009; 25; 2: 332-338. 10.1016/j.chb.2008.12.019

Kim C, Yuan J, Vasconcelos L, Shin M, Hill RB. Debugging during block-based programming. Instructional Science. 2018; 46; 5: 767-787. 10.1007/s11251-018-9453-5

Krishnamurthi, S, & Fisler, K. (2019). Programming paradigms and beyond. In S. Fincher & A. Robins (Eds.), The Cambridge handbook of computing education research (pp. 377--413). Cambridge University Press. https://doi.org/10.1017/9781108654555.014

Kwon K. Novice programmer's misconception of programming reflected on problem-solving plans. International Journal of Computer Science Education in Schools. 2017; 1; 4: 14-24. 10.21585/ijcses.v1i4.19

Lin, M. H, Chen, M. P, & Chen, C. F. (2013). Exploring peer scaffolding opportunities on experiential problem solving learning. In C. Bǎdicǎ, N. T. Nguyen, & M. Brezovan (Eds.), International conference on computational collective intelligence (pp. 572–581). Springer. https://doi.org/10.1007/978-3-642-40495-5_57

Liu CC, Cheng YB, Huang CW. The effect of simulation games on the learning of computational problem solving. Computers & Education. 2011; 57; 3: 1907-1918. 10.1016/j.compedu.2011.04.002

Luxton-Reilly, A, Simon, Albluwi, I, Becker, B. A, Giannakos, M, Kumar, A. N, Ott, L, Paterson, J, Scott, M. J, Sheard, J, & Szabo, C. (2018). Introductory programming: A systematic literature review. In Proceedings Companion of the 23rd Annual ACM conference on innovation and technology in computer science education (pp. 55–106). https://doi.org/10.1145/3293881.3295779

Lye SY, Koh JHL. Review on teaching and learning of computational thinking through programming: What is next for K-12?. Computers in Human Behavior. 2014; 41: 51-61. 10.1016/j.chb.2014.09.012

Maloney J, Resnick M, Rusk N, Silverman B, Eastmond E. The scratch programming language and environment. ACM Transactions on Computing Education (TOCE). 2010; 10; 4: 1-15. 10.1145/1868358.1868363

Mazlan, U. H. & Othman, M. (2015). Fundamentals of algorithm design course: Issues, challenges & proposed teaching-learning approaches. In T. R. Razak, M. H. Ismail, & A. F. Ibrahim (Eds.), Colloquium in Computer & Mathematical Sciences Education 2015 (pp. 18–22).

Meerbaum-Salant, O, Armoni, M, & Ben-Ari, M. M. (2010). Learning computer science concepts with Scratch. In Proceedings of the sixth International Workshop on computing education research (pp. 69–76). https://doi.org/10.1080/08993408.2013.832022

Nicholson, J. (2020). New digital economy estimates. United States Bureau of Economic Analysis. https://www.bea.gov/system/files/2020-08/New-Digital-Economy-Estimates-August-2020.pdf

Pea RD, Kurland DM. On the cognitive effects of learning computer programming. New Ideas in Psychology. 1984; 2; 2: 137-168. 10.1016/0732-118X(84)90018-7

Piteira, M, & Costa, C. (2013). Learning computer programming: Study of difficulties in learning programming. In Proceedings of the 2013 International Conference on Information Systems and Design of Communication (pp. 75–80). ACM. https://doi.org/10.1145/2503859.2503871

Price, T. W, & Barnes, T. (2015). Comparing textual and block interfaces in a novice programming environment. In Proceedings of the eleventh annual international conference on international computing education research (pp. 91–99). https://doi.org/10.1145/2787622.2787712

Robins, A. V. (2019). Novice programmers and introductory programming. In S. Fincher & A. Robins (Eds.), The Cambridge handbook of computing education research (pp. 327–376). Cambridge University Press. https://doi.org/10.1017/9781108654555.013

Sáez-López JM, Román-González M, Vázquez-Cano E. Visual programming languages integrated across the curriculum in elementary school: A two year case study using "Scratch" in five schools. Computers & Education. 2016; 97: 129-141. 10.1016/j.compedu.2016.03.003

Slevin E, Sines D. Enhancing the truthfulness, consistency and transferability of a qualitative study: Utilising a manifold of approaches. Nurse Researcher. 1999; 7; 2: 79-97. 10.7748/nr2000.01.7.2.79.c6113

Statter D, Armoni M. Teaching Abstraction in Computer Science to 7th Grade Students. ACM Transactions on Computing Education (TOCE). 2020; 20; 1: 1-37. 10.1145/3372143

Sweller J, van Merriënboer JJG, Paas F. Cognitive architecture and instructional design: 20 years later. Educational Psychology Review. 2019; 31: 261-292. 10.1007/s10648-019-09465-5

Tissenbaum, M, Sheldon, J, Sherman, M. A, Abelson, H, Weintrop, D, Jona, K, Horn, M, Wilensky, U, Basu, S, Rutstein, D, Snow, E, Shear, L, Grover, S, Lee, I, Klopfer, E, Jayathirtha, G, Shaw, M, Kafai, y, Mustafaraj, E, Temple, W, Shapiro, R. B, Lui, D, & Sorensen, C. (2018). The state of the field in computational thinking assessment. In Kay, J. and Luckin, R. (Eds.) Rethinking Learning in the Digital Age: Making the Learning Sciences Count, 13th International Conference of the Learning Sciences (ICLS) 2018 (Vol. 2). International Society of the Learning Sciences. https://repository.isls.org//handle/1/609

Tshukudu, E, & Cutts, Q. (2020). Semantic transfer in programming languages: Exploratory study of relative novices. In Proceedings of the 2020 ACM Conference on Innovation and Technology in Computer Science Education (pp. 307–313). https://doi.org/10.1145/3341525.3387406

U.S. Bureau of Labor Statistics. (2020). Fastest growing occupations, 2019 and projected 2029. Retrieved from June 30, 2021 from https://www.bls.gov/emp/tables/fastest-growing-occupations.htm

Vihavainen, A, Airaksinen, J, & Watson, C. (2014). A systematic review of approaches for teaching introductory programming and their influence on success. In Proceedings of the tenth annual conference on international computing education research (pp. 19–26). https://doi.org/10.1145/2632320.2632349

Vogel, S, Santo, R, & Ching, D. (2017). Visions of computer science education: Unpacking arguments for and projected impacts of CS4All initiatives. In Proceedings of the 2017 ACM SIGCSE technical symposium on computer science education (pp. 609–614). https://doi.org/10.1145/3017680.3017755

Weintrop, D. & Wilensky, U. (2019). Transitioning from introductory block-based and text-based environments to professional programming languages in high school computer science classrooms. Computers & Education. 142. https://doi.org/10.1016/j.compedu.2019.103646

Weintrop D, Beheshti E, Horn M, Orton K, Jona K, Trouille L, Wilensky U. Defining computational thinking for mathematics and science classrooms. Journal of Science Education and Technology. 2016; 25; 1: 127-147. 10.1007/s10956-015-9581-5

Weintrop D, Wilensky U. How block-based languages support novices: A framework for categorizing block-based affordances. Journal of Visual Languages and Sentient Systems. 2017; 3: 92-100. 10.18293/VLSS2017-006

Wing JM. Computational thinking. Communications of the ACM. 2006; 49; 3: 33-35. 10.1145/1118178.1118215

Wing JM. Computational thinking and thinking about computing. Philosophical Transactions of the Royal Society a: Mathematical, Physical and Engineering Sciences. 2008; 366; 1881: 3717-3725. 10.1098/rsta.2008.0118

Xu Z, Ritzhaupt AD, Tian F, Umapathy K. Block-based versus text-based programming environments on novice student learning outcomes: A meta-analysis study. Computer Science Education. 2019; 29; 2–3: 177-204. 10.1080/08993408.2019.1565233

Zehetmeier, D, Böttcher, A, Brüggemann-Klein, A, & Thurner, V. (2019). Defining the competence of abstract thinking and evaluating CS-students' level of abstraction. In Proceedings of the 52nd Hawaii International conference on system sciences.https://doi.org/10.24251/HICSS.2019.921

By Minji Jeon and Kyungbin Kwon

Reported by Author; Author