Blue - A Language for Teaching Object-Oriented Programming

Teaching object-oriented programming has clearly become an important part of computer science education. We agree with many others that the best place to teach it is in the CS1 introductory course. Many problems with this have been reported in the literature. These mainly result from inadequate languages and environments. Blue is a new language and integrated programming environment, currently under development explicitly for object-oriented teaching. We expect clear advantages from the use of Blue for first year teaching compared to using other available languages. This paper describes the design principles on which the language was based and the most important aspects of the language itself

Semantic Parsing of Java I/O in Novice Programs for an Online Grading System

Beginning programming students have access to sophisticated development tools that enable them to write syntactically correct code in a straightforward manner. However, code that compiles and runs can still execute poorly, or with unintended results. We present a tool, based on an open-source parser-generation product written in Java, that performs semantic analysis of novice Java code. Specifically, the present investigation concerns the semantics of Java output methods, particularly when they are enclosed within iterative structures in the language. The effort will be to guard against threats that such methods pose to system integrity and performance, intercepting them prior to runtime. The approach used here closely models the analysis a human reviewer would perform, given a printed copy of the code. The tool is an open-source product, like the parser generator, and is also written in Java. As such, it is written to be extensible. The tool will be integrated into a larger research project underway at Montclair State University which involves the development of an online grading system for students in beginning computer programming courses

Julia: A Fresh Approach to Numerical Computing

Bridging cultures that have often been distant, Julia combines expertise from the diverse fields of computer science and computational science to create a new approach to numerical computing. Julia is designed to be easy and fast. Julia questions notions generally held as "laws of nature" by practitioners of numerical computing: 1. High-level dynamic programs have to be slow. 2. One must prototype in one language and then rewrite in another language for speed or deployment, and 3. There are parts of a system for the programmer, and other parts best left untouched as they are built by the experts. We introduce the Julia programming language and its design --- a dance between specialization and abstraction. Specialization allows for custom treatment. Multiple dispatch, a technique from computer science, picks the right algorithm for the right circumstance. Abstraction, what good computation is really about, recognizes what remains the same after differences are stripped away. Abstractions in mathematics are captured as code through another technique from computer science, generic programming. Julia shows that one can have machine performance without sacrificing human convenience.Comment: 37 page

Musical Program Auralisation: Empirical Studies

Program auralisation aims to communicate information about program state, data, and behaviour using audio. We have argued that music offers many advantages as a communication medium [1]. The CAITLIN system [4, 16, 17, 18] was constructed to provide auralisations within a formal structured musical framework. Pilot studies [4, 16] showed that programmers could infer program structure from auralisations alone. A study was conducted using twenty-two novice programmers to assess a) whether novices could understand the musical auralisations and b) whether the musical experience and knowledge of subjects affected their performance. The results show that novices could interpret the auralisations (with accuracy varying across different levels of abstraction) and that musical knowledge had no significant effect on performance. A second experiment was conducted with another twenty-two novice programmers to study the effects of musical program auralisation on debugging tasks. The experiment aimed to determine whether auralisations would lead to higher bug detection rates. The results indicate that, in certain circumstances, musical auralisations can be used to help locate bugs in programs and that musical skill does not affect the ability to make use of the auralisations. In addition, it the experiment showed that subjective workload increased when the musical auralisations were used

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

An Exploration of High School Students' Self-Confidence while Analysing Iterative Code

A number of studies on novice programming report that loops and conditionals can be potential sources of errors and misconceptions. We then felt the need to engage in a more systematic and in-depth investigation about the teaching and learning of iteration in some representative high schools of our regional area. As a medium-term outcome of this endeavour we expect to get fine-grained insights about the nature of students' difficulties, on the one hand, as well as to identify possible pedagogical approaches to be adopted by teachers, on the other. As a step of this project, we designed and administered a survey composed of a set of small tasks, addressing students’ understanding of iteration in terms of code reading abilities. After summarising the motivations underlying the choice of the tasklets and the overall structure of the instrument, in this paper we will focus on a particular aspect which has not yet received extensive attention in the computer science education literature. Specifically, we will consider students' perception of self-confidence, in connection with their actual performance in each task, the specific program features, the cognitive demands (procedural vs. higher-level thinking skills), and the use of code vs. flow-charts. A noteworthy result of this analysis is that students’ perception of self-confidence is poorly correlated to actual performance in the task at hand. The main implications of our study are twofold, pertaining our understanding of less conspicuous facets of the learning of iteration as well as possible pedagogical strategies to strengthen metacognitive skills

1957-2007: 50 Years of Higher Order Programming Languages

Fifty years ago one of the greatest breakthroughs in computer programming and in the history of computers happened – the appearance of FORTRAN, the first higher-order programming language. From that time until now hundreds of programming languages were invented, different programming paradigms were defined, all with the main goal to make computer programming easier and closer to as many people as possible. Many battles were fought among scientists as well as among developers around concepts of programming, programming languages and paradigms. It can be said that programming paradigms and programming languages were very often a trigger for many changes and improvements in computer science as well as in computer industry. Definitely, computer programming is one of the cornerstones of computer science. Today there are many tools that give a help in the process of programming, but there is still a programming tasks that can be solved only manually. Therefore, programming is still one of the most creative parts of interaction with computers. Programmers should chose programming language in accordance to task they have to solve, but very often, they chose it in accordance to their personal preferences, their beliefs and many other subjective reasons. Nevertheless, the market of programming languages can be merciless to languages as history was merciless to some people, even whole nations. Programming languages and developers get born, live and die leaving more or less tracks and successors, and not always the best survives. The history of programming languages is closely connected to the history of computers and computer science itself. Every single thing from one of them has its reflexions onto the other. This paper gives a short overview of last fifty years of computer programming and computer programming languages, but also gives many ideas that influenced other aspects of computer science. Particularly, programming paradigms are described, their intentions and goals, as well as the most of the significant languages of all paradigms

Toward Predicting Success and Failure in CS2: A Mixed-Method Analysis

Factors driving success and failure in CS1 are the subject of much study but less so for CS2. This paper investigates the transition from CS1 to CS2 in search of leading indicators of success in CS2. Both CS1 and CS2 at the University of North Carolina Wilmington (UNCW) are taught in Python with annual enrollments of 300 and 150 respectively. In this paper, we report on the following research questions: 1) Are CS1 grades indicators of CS2 grades? 2) Does a quantitative relationship exist between CS2 course grade and a modified version of the SCS1 concept inventory? 3) What are the most challenging aspects of CS2, and how well does CS1 prepare students for CS2 from the student's perspective? We provide a quantitative analysis of 2300 CS1 and CS2 course grades from 2013--2019. In Spring 2019, we administered a modified version of the SCS1 concept inventory to 44 students in the first week of CS2. Further, 69 students completed an exit questionnaire at the conclusion of CS2 to gain qualitative student feedback on their challenges in CS2 and on how well CS1 prepared them for CS2. We find that 56% of students' grades were lower in CS2 than CS1, 18% improved their grades, and 26% earned the same grade. Of the changes, 62% were within one grade point. We find a statistically significant correlation between the modified SCS1 score and CS2 grade points. Students identify linked lists and class/object concepts among the most challenging. Student feedback on CS2 challenges and the adequacy of their CS1 preparations identify possible avenues for improving the CS1-CS2 transition.Comment: The definitive Version of Record was published in 2020 ACM Southeast Conference (ACMSE 2020), April 2-4, 2020, Tampa, FL, USA. 8 page