As Scratch has become one of the most popular educational programming languages, understanding its common programming idioms can benefit both computing educators and learners. This understanding can fine-tune the curricular development to help learners master the fundamentals of writing idiomatic code in their programming pursuits. Unfortunately, the research community's understanding of what constitutes idiomatic Scratch code has been limited. To help bridge this knowledge gap, we systematically identified idioms as based on canonical source code, presented in widely available educational materials. We implemented a tool that automatically detects these idioms to assess their prevalence within a large dataset of over 70K Scratch projects in different experience backgrounds and project categories. Since communal learning and the practice of remixing are one of the cornerstones of the Scratch programming community, we studied the relationship between common programming idioms and remixes. Having analyzed the original projects and their remixes, we observed that different idioms may associate with dissimilar types of code changes. Code changes in remixes are desirable, as they require a meaningful programming effort that spurs the learning process. The ability to substantially change a project in its remixes hinges on the project's code being easy to understand and modify. Our findings suggest that the presence of certain common idioms can indeed positively impact the degree of code changes in remixes. Our findings can help form a foundation of what comprises common Scratch programming idioms, thus benefiting both introductory computing education and Scratch programming tools.
As a popular language for teaching introductory programming, Java can profoundly influence beginner programmers with its coding style and idioms. Despite its many advantages, the paradigmatic coding style in Java is often described as verbose. As a result, when writing code in more concise languages, such programmers tend to emulate the familiar Java coding idioms, thus neglecting to take advantage of the more succinct counterparts in those languages. As a result of such verbosity, not only the overall code quality suffers, but the verbose non-idiomatic patterns also render code hard to understand and maintain. In this paper, we study the incidences of Java-like verbosity as they occur in Python codebases. We present a collection of Java-Like Verbosity Anti-patterns and our pilot study of their presence in representative open-source Python codebases. We discuss our findings as a call for action to computing educators, particularly those who work with introductory students. We need novel pedagogical interventions that encourage budding programmers to write concise idiomatic code in any language.
Compilers are large software systems. In course projects it is often a challenge for students to build a significant compiler on their own with features like memory management, closures, inheritance, and more. We report on our experience splitting a relatively large compiler, with several of these advanced features, among project groups in a graduate compilers course. In addition to allowing students to engage with a larger system than groups would have been able to build on their own, we also believe based on anecdotal feedback that this had positive effects on student morale and community. There were several concrete logistics and content decisions we made that were effective, along with other recommendations and refinements for when we run the course again.
DevOps is a set of practices in software engineering that is in high demand by industry. It is a dynamic field which constantly adds new methods and tools. Teaching DevOps prepares today’s computer science students for best-practices in a working environment but challenges university lecturers to provide central concepts while staying up-to-date with current trends. In this paper we report and reflect on our experiences teaching DevOps at two universities (in the USA and Germany) in an inverted classroom format. We describe how we set-up the courses, provide a brief analysis of data we collected, and share our lessons learned.
Enrollment in programming courses increasingly surges. To maintain the quality of education in programming courses, instructors need ways to understand the performance of students and give feedback accordingly at scale. For example, it is important for instructors to identify different problem-solving ways (named as tactics in this paper) used in programming submissions. However, because there exist many abstraction levels of tactics and high implementation diversity of the same tactic, it is challenging and time-consuming for instructors to manually tackle the task of tactic identification. Toward this task, we propose PaCon, a symbolic analysis approach for clustering functionally correct programming submissions to provide a way of identifying tactics. In particular, PaCon clusters submissions according to path conditions, a semantic feature of programs. Because of the focus on program semantics, PaCon does not struggle with the issue of an excessive number of clusters caused by subtle syntactic differences between submissions. Our experimental results on real-world data sets show that PaCon can produce a reasonable number of clusters each of which effectively groups together those submissions with high syntax diversity while sharing equivalent path-condition-based semantics, providing a promising way toward identifying tactics.
Machine learning methods are increasingly leveraged in disparate domains of research. Herein, we describe our curriculum design to introduce undergraduate students to applied research through a series of course assignments and a competition among peers to inspire other educators. We describe the overall course structure and detail how the assignments were tailored to a selected open research question while developing student understanding of machine learning. We outline the lessons learned from this new undergraduate curriculum design and describe how it may be adapted to similar courses. For the selected COVID19-related course-long problem of predicting which drugs might interact with specific proteins, we leveraged state-of-the-art tools for representing drug and protein sequences. We challenged students to develop unique solutions competitive with a current state-of-the-art model using reproducible Notebooks and cloud-based computing resources with the expectation that top-ranking solutions would be used to predict novel druggable targets within the SARS-CoV-2 proteome to possibly treat COVID19 patients. We motivate this curriculum design based on related competition frameworks that have led to notable research advancements and contributed to machine learning pedagogy. From our experience, the top student solutions were ultimately combined using a stacked classifier to create a publishable solution representing an actual research contribution. We highly recommend introducing undergraduate students to open research applications early in their program to encourage them to consider pursuing a career in research.
In this essay, we explore a new pedagogical framing ofway of pedagogically and teaching the Liskov Substitution Principle (LSP). In addition to, or perhaps even in place of, teaching the specifics of the rule itself, we advocatepropose teaching an operationalised version of the rule: that a subtype must pass its supertype’s black box tests for each of its overriding methods. We leverage the fact that black box tests should be written to capture conformance to a specification without overfitting or checking implementation internalsdetails (as would be checked by glass box tests). A type that violates the rules of substitutability will also fail a potential corresponding black box test for the supertype. Additionally, we argue that the over-strict nature of the classical LSP Postcondition Rule (which has been improved in subsequent work) can be a source of confusion for both instructors and for students learning this crucial concept for the first time. Pleasingly, many of the technical subtleties of this nuanced but important concept drop out naturally when thinking of substitutability via black box tests. Thus we put forward We propose that this test-oriented means of teaching substitutability is a valuable alternative to the classical sense of checking the LSP, with the benefit of being intuitively accessible to students.
To facilitate assisting students while online during the COVID 19 pandemic, we transitioned to online office hours. These were managed by an automated queue which kept track of who was waiting in office hours, and for how long. We combined data about office hour usage with students' project commit and grade history. These data afforded us a unique look at the efficacy of office hours that the usual, casual drop-in style office hours, did not allow. Amongst other findings, we saw that while individual office hours visits did increase student grades, more visits during the term was negatively correlated with the final project outcome.
The atomic entity of digital audio processing systems is a digital audio signal, i.e. a sequence of sound samples that represent the amplitude of a sound wave at discrete time intervals. Such signals are transformed additively, by combining them into more complex signals, and subtractively, by subjecting them to digital filters. In order to cover digital audio processing in a classroom from first principles, we need to form collections of samples in streams or arrays, and define operations on these collections in accordance with the constraints of digitization. In this work, we pursue an alternative approach, where the atomic entity is a continuous wave function. We present additive synthesis operations, including wave envelopes and musical abstractions in a purely functional setting. The final continuous wave function is digitized in order to make the sound audible. We report our experiences with what we call functional audio processing as an example domain for teaching functional programming to first-year students, where simplicity and conceptual elegance outweighs the inherent limitation to additive synthesis. We describe a sequence of teachable moments that highlight the potential of functional audio processing at an early stage in the learning process, before streams or arrays are introduced.
The first two chapters of the introductory computer science textbook Structure and Interpretation of Computer Programs, JavaScript Adaptation (SICP JS), use a subset of JavaScript called Source §2. The book introduces the reduction-based “substitution model” as a first mental model for the evaluation of Source §2 programs. To support the learner in adopting this mental model, we built an algebraic stepper—a tool for visualizing the evaluation of Source §2 programs according to the model. As a sublanguage of JavaScript, Source §2 differs from other purely functional programming languages by using a statement-oriented syntax, with statement sequences, return statements, and block-scoped declarations. For the purpose of this tool description, we distill these distinguishing features—along with explicit recursion—into a Source §2 sublanguage that we call Source §0, and focus on a stepper for this language. We formalize the substitution model of Source §0 as a lambda-calculus-style reduction semantics that handles explicit recursion by term graph rewriting and faithfully implements the JavaScript specification, when restricted to that language. Our implementation of the stepper represents term graphs by persistent data structures that maximize sharing and enable random access to all steps. This work presents the first reduction-based semantics for a JavaScript sublanguage and the first algebraic stepper for a language with return statements and block-scoped declarations. The tool supports the learner with step-level explanations, redex highlighting, and function-level skipping and can also be used for teaching the applicative-order-reduction lambda calculus.
First-year students benefit from robotics-based programming exercises by learning how to use sensors to gain information on the (changing) world surrounding the robot, how to model this information using data structures, and how to design algorithms for performing meaningful activities. Robotics-based exercises are naturally experiential and team-based and provide among the most memorable teachable moments of first-year programming courses. We summarize the pedagogical challenges that robotics-based exercises face, even under ideal circumstances, and how a university responded to these challenges. We report on the additional challenges faced in late 2020 at the same university as a result of the COVID pandemic, and how the course staff addressed these challenges using programming language implementation and network tools. The crucial components were (1) a custom-built web-based development environment with collaborative features including a built-in compiler, (2) a portable virtual machine, (3) collaborative editing, (4) open source protocols, and (5) peer-to-peer teleconferencing software. We report on the lessons learnt and how to further improve the resilience of robotics-based programming exercises.
In teaching and learning programming at first-year-university level, simple languages with small feature sets are preferable over industry-strength languages with extensive feature sets, to reduce the learners' cognitive load. At the same time, there is increasing pressure to familiarise students with mainstream languages early in their learning journey, and these languages accumulate features as years go by. In response to these competing requirements, we developed Source, a collection of JavaScript sublanguages with feature sets just expressive enough to introduce first-year computer science students to the elements of computation. These languages are supported by a web-based programming environment custom-built for learning at beginner's level, which provides transpiler, interpreter, virtual machine, and algebraic-stepper-based implementations of the languages, and includes tracing, debugging, visualization, type-inference, and smart-editor features. This paper motivates the choice of JavaScript as starting point and describes the syntax and semantics of the Source languages compared to their parent language, and their implementations in the system. We report our experiences in developing and improving the languages and implementations over a period of three years, teaching a total of 1561 computer science first-year students at a university.