Novice Programmers' Reasoning About Reversing Conditional Statements

We want undergraduate students to develop higher-order thinking skills that enable them to master program behaviour. Nonetheless, many students of both introductory and advanced programming courses appear to struggle with the abstraction required for this purpose. In particular, a recent think-aloud study showed a group of students were able to reason about and reverse the effect of assignments and vector updates, but most of them failed when asked to reverse a seemingly simple conditional statement. We have extended that study by assigning a similar task to two cohorts of novice programmers as part of their final exam paper. Students' answers, including code and short explanations, have been analysed through the lens of the SOLO taxonomy: 28% of the solutions were correct (classified as relational); an additional 23% were partially correct but failed to identify the overlap between the two paths of the conditional statement (classified as multistructural). Furthermore, the concept of reversibility and related ``low-ceiling'' tasks, such as the one discussed in this study, could be useful resources for educators to assess and develop students' understanding of program behaviour

An Exploration of Novice Programmers' Comprehension of Conditionals in Imperative and Functional Programming

2Students of introductory programming courses are expected to develop higher-order thinking skills to inspect, understand and modify code. However, although novices can correctly write small programs, they appear to lack a more abstract, comprehensive grasp of basic constructs, such as conceiving the overall effect of alternative conditional flows. This work takes a little-explored perspective on the comprehension of tiny programs by asking students to reason about reversing conditionals in either an imperative or a functional context. More specifically, besides deciding if the given constructs can be reversed, students had to justify their choice by writing a reversing program or by providing suitable counterexamples. The students’ answers to four reversibility questions have been analysed through the lens of the SOLO taxonomy. 45% of students correctly identified the reversibility for the four code items; furthermore, more than 50% of each cohort were able to provide correct justifications for at least three of their four answers. Most incorrect answers were due to failures to consider border cases or to edit the conditional expressions appropriately to reverse the construct. Differences in comprehension between functional and imperative languages are explored indicating the explicit else paths of the functional examples facilitate comprehension compared with the implicit else (no update) of its imperative counterpart.partially_openopenMirolo, Claudio; Izu, CruzMirolo, Claudio; Izu, Cru

High-school students' mastery of basic flow-control constructs through the lens of reversibility

High-school students specialising in computing fields need to develop the abstraction skills required to understand and create programs. Novices' difficulties at high-school level, ranging from mastery of the "notional machine"to recognition of a program's purpose, have not been investigated as extensively as at tertiary level. This work explores high-school students' code comprehension by asking to reason about reversing conditional and iteration constructs. A sample of 205 K11 - 13 students from different institutions were asked to engage in a set of "reversibility tasklets". For each code fragment, they need to identify if its computation is reversible and either provide the code to reverse or an example of a value that cannot be reversed. For 4 such items, after extracting the recurrent patterns in students' answers, we have carried out an analysis within the framework of the SOLO taxonomy. Overall, 74% of answers correctly identified if the code was reversible but only 42% could provide the full explanation/code. The rate of relational answers varies from 51% down to 21%, the poorest performance arising for a small array-processing loop (and although 65% of the subjects had correctly identified the loop as reversible). The instruction level did not have a strong impact on performance, indicating such tasks are suitable for K11, when the basic flow-control constructs are usually introduced. In particular, the reversibility concept could be a useful pedagogical instrument both to assess and to help develop students' program comprehension

Comparing Small Programs for Equivalence: A Code Comprehension Task for Novice Programmers

Novice programmers should develop program comprehension skills as they learn to code so that they are able both to read and reason about code created by others, and to reflect on their code when writing, debugging or extending it. This work takes a little-explored perspective on the comprehension of small programs by asking students to decide if two code segments are equivalent or not in terms of carrying out the same computation. A variation of Euclid's algorithm, that extends the greatest common divisor calculation to more than two numbers, was chosen for this work, as it has an adequate level of complexity and its semantics are not obvious. Four program transformations of the original code were developed: two transformations were equivalent and two were not. 73.5% of students were able to identify correctly the four options and 75.5% provided good insights on the equivalent program flow to justify their choices. The overall task has a SOLO mean of 3.19, which indicates code equivalence is a suitable and approachable task to analyse program execution at novice level. In addition, the data analysis suggests that students' code-reading abilities beyond basic tracing may be generally underestimated and we should investigate how to bridge the potential gap between reasoning about program execution and extracting its purpose

Fostering Program Comprehension in Novice Programmers - Learning Activities and Learning Trajectories

This working group asserts that Program Comprehension (ProgComp) plays a critical part in the process of writing programs. For example, this paper is written from a basic draft that was edited and revised until it clearly presented our idea. Similarly, a program is written incrementally, with each step tested, debugged and extended until the program achieves its goal. Novice programmers should develop program comprehension skills as they learn to code so that they are able both to read and reason about code created by others, and to reflect on their code when writing, debugging or extending it. To foster such competencies our group identified two main goals: (g1) to collect and define learning activities that explicitly address key components of program comprehension and (g2) to define tentative theoretical learning trajectories that will guide teachers as they select and sequence those learning activities in their CS0/CS1/CS2 or K-12 courses. The WG has completed the first goal and laid down a strong foundation towards the second goal as presented in this report. After a thorough literature review, a detailed description of the Block Model is provided, as this model has been used with a dual purpose, to classify and present an extensive list of ProgComp tasks, and to describe a possible learning trajectory for a complex task, covering different cells of the Block Model matrix. The latter is intended to help instructors to decompose complex tasks and identify which aspects of ProgComp are being fostered

Task-related models for teaching and assessing iteration learning in high school

A number of studies report about students’ difficulties with basic flow-control constructs, and specifically with iteration. Although such issues are less explored in the context of pre-tertiary education, this seems to be especially the case for high-school programming learning, where the difficulties concern both the “mechanical” features of the notional machine as well as the logical aspects connected with the constructs, ranging from the implications of loop conditions to a more abstract grasp of the underlying algorithms. For these reasons, the aim of this work is to: i) identifying methodological tools to enhance a comprehensive understanding of the iteration constructs, ii) suggest strategies to teach iterations. We interviewed 20 experienced upper secondary teachers of introductory programming in different kinds of schools. The interviews were mainly aimed at ascertaining teachers’ beliefs about major sources of issues for basic programming concepts and their approach to the teaching and learning of iteration constructs. Once teachers’ perception of students’ difficulties have been identified, we have submitted, to a sample of 164 students, a survey which included both questions on their subjective perception of difficulty and simple tasks probing their understanding of iteration. Data collected from teachers and students confirm that iteration is a central programming concept and indicate that the treatment of conditions and nested constructs are major sources of students’ difficulties with iteration. The interviews allowed us to identify a list of problems that are typically presented by teachers to explain the iterations. Hence, a catalogue of significant program examples has been built to support students’ learning, tasks with characteristics different from those typically presented in class. Based on the outcome of previous steps, a survey to collect related information and good practices from a larger sample of teachers has been designed. Data collected have been analysed distinguishing an orientation towards more conceptual objectives, and one towards more practical objectives. Furthermore, regarding evaluation, a orientation focused on process-based assessment and another on product-based assessment. Finally, based on the outcome of previous students’ survey and drawing from the proposed examples catalogue, we have designed and submitted a new students’ survey, composed of a set of small tasks, or tasklets, to investigate in more depth on high-school students’ understanding of iteration in terms of code reading abilities. The chosen tasklets covered the different topics: technical program feature, correlation between tracing effort and abstraction, the role of flow-charts, students’ perception of self-confidence concerning high-level thinking skills.A number of studies report about students’ difficulties with basic flow-control constructs, and specifically with iteration. Although such issues are less explored in the context of pre-tertiary education, this seems to be especially the case for high-school programming learning, where the difficulties concern both the “mechanical” features of the notional machine as well as the logical aspects connected with the constructs, ranging from the implications of loop conditions to a more abstract grasp of the underlying algorithms. For these reasons, the aim of this work is to: i) identifying methodological tools to enhance a comprehensive understanding of the iteration constructs, ii) suggest strategies to teach iterations. We interviewed 20 experienced upper secondary teachers of introductory programming in different kinds of schools. The interviews were mainly aimed at ascertaining teachers’ beliefs about major sources of issues for basic programming concepts and their approach to the teaching and learning of iteration constructs. Once teachers’ perception of students’ difficulties have been identified, we have submitted, to a sample of 164 students, a survey which included both questions on their subjective perception of difficulty and simple tasks probing their understanding of iteration. Data collected from teachers and students confirm that iteration is a central programming concept and indicate that the treatment of conditions and nested constructs are major sources of students’ difficulties with iteration. The interviews allowed us to identify a list of problems that are typically presented by teachers to explain the iterations. Hence, a catalogue of significant program examples has been built to support students’ learning, tasks with characteristics different from those typically presented in class. Based on the outcome of previous steps, a survey to collect related information and good practices from a larger sample of teachers has been designed. Data collected have been analysed distinguishing an orientation towards more conceptual objectives, and one towards more practical objectives. Furthermore, regarding evaluation, a orientation focused on process-based assessment and another on product-based assessment. Finally, based on the outcome of previous students’ survey and drawing from the proposed examples catalogue, we have designed and submitted a new students’ survey, composed of a set of small tasks, or tasklets, to investigate in more depth on high-school students’ understanding of iteration in terms of code reading abilities. The chosen tasklets covered the different topics: technical program feature, correlation between tracing effort and abstraction, the role of flow-charts, students’ perception of self-confidence concerning high-level thinking skills

Effectiveness of training on algorithms versus notation for indirect addressing comprehension

This study compared two units of instruction for overcoming difficulties of beginning programmers in understanding and implementing strategies of indirect addressing. One of the units emphasized the algorithms in which indirection was used, whereas the other unit emphasized indirect notation. Both instructional units were delivered by computer to two introduction to Pascal programming classes. Students in each class were randomly divided so that each student used one or the other of the two units;These units were used prior to and were supplementary to three lectures covering indirect notation. The effectiveness of the units were determined by two posttests. One posttest, requiring students to select subscripts at several levels of indirection, was administered by computer. This test was very similar to the activities in the notation unit. The second posttest was a paper pencil activity requiring the students to complete or modify sorting algorithms in which indirection was used;Because of the explorative nature of this study and the small sample size, the findings must be viewed as tentative. However, it would appear the notation of indirection by itself is not an important source of student problems in this area. In fact, there was little evidence to suggest that either unit made a sizeable difference in the student\u27s ability to deal with indirection within the context of programming. There was an indication extra study of algorithms encouraged students to attempt to solve more problems, but this finding may be a result of the experimental conditions and may not be generalizable

A study of novice programmer performance and programming pedagogy.

Identifying and mitigating the difficulties experienced by novice programmers is an active area of research that has embraced a number of research areas. The aim of this research was to perform a holistic study into the causes of poor performance in novice programmers and to develop teaching approaches to mitigate them. A grounded action methodology was adopted to enable the primary concepts of programming cognitive psychology and their relationships to be established, in a systematic and formal manner. To further investigate novice programmer behaviour, two sub-studies were conducted into programming performance and ability. The first sub-study was a novel application of the FP-Tree algorithm to determine if novice programmers demonstrated predictable patterns of behaviour. This was the first study to data mine programming behavioural characteristics rather than the learner’s background information such as age and gender. Using the algorithm, patterns of behaviour were generated and associated with the students’ ability. No patterns of behaviour were identified and it was not possible to predict student results using this method. This suggests that novice programmers demonstrate no set patterns of programming behaviour that can be used determine their ability, although problem solving was found to be an important characteristic. Therefore, there was no evidence that performance could be improved by adopting pedagogies to promote simple changes in programming behaviour beyond the provision of specific problem solving instruction. A second sub-study was conducted using Raven’s Matrices which determined that cognitive psychology, specifically working memory, played an important role in novice programmer ability. The implication was that programming pedagogies must take into consideration the cognitive psychology of programming and the cognitive load imposed on learners. Abstracted Construct Instruction was developed based on these findings and forms a new pedagogy for teaching programming that promotes the recall of abstract patterns while reducing the cognitive demands associated with developing code. Cognitive load is determined by the student’s ability to ignore irrelevant surface features of the written problem and to cross-reference between the problem domain and their mental program model. The former is dealt with by producing tersely written exercises to eliminate distractors, while for the latter the teaching of problem solving should be delayed until the student’s program model is formed. While this does delay the development of problem solving skills, the problem solving abilities of students taught using this pedagogy were found to be comparable with students taught using a more traditional approach. Furthermore, monitoring students’ understanding of these patterns enabled micromanagement of the learning process, and hence explanations were provided for novice behaviour such as difficulties using arrays, inert knowledge and “code thrashing”. For teaching more complex problem solving, scaffolding of practice was investigated through a program framework that could be developed in stages by the students. However, personalising the level of scaffolding required was complicated and found to be difficult to achieve in practice. In both cases, these new teaching approaches evolved as part of a grounded theory study and a clear progression of teaching practice was demonstrated with appropriate evaluation at each stage in accordance with action researc

Crossed Wires: Investigating the Problems of End-User Developers in a Physical Computing Task

Considerable research has focused on the problems that end users face when programming software, in order to help them overcome their difficulties, but there is little research into the problems that arise in physical computing when end users construct circuits and program them. In an empirical study, we observed end-user developers as they connected a temperature sensor to an Arduino microcontroller and visualized its readings using LEDs. We investigated how many problems participants encountered, the problem locations, and whether they were overcome. We show that most fatal faults were due to incorrect circuit construction, and that often problems were wrongly diagnosed as program bugs. Whereas there are development environments that help end users create and debug software, there is currently little analogous support for physical computing tasks. Our work is a first step towards building appropriate tools that support end-user developers in overcoming obstacles when constructing physical computing artifacts