https://blog.brownplt.org/2022/07/09/plan-comp-hof.html The Brown PLT Blog [brownplt] RSS CONTACT GROUP PAGE PREVIOUS POSTS * Plan Composition Using Higher-Order Functions * Towards a Notional Machine for Runtime Stacks and Scope * Gradual Soundness: Lessons from Static Python * Applying Cognitive Principles to Model-Finding Output * Automated, Targeted Testing of Property-Based Testing Predicates * A Benchmark for Tabular Types * Student Help-Seeking for (Un)Specified Behaviors * Adding Function Transformers to CODAP * Developing Behavioral Concepts of Higher-Order Functions * Adversarial Thinking Early in Post-Secondary Education * Teaching and Assessing Property-Based Testing * Students Testing Without Coercion * Using Design Alternatives to Learn About Data Organizations * What Help Do Students Seek in TA Office Hours? * Combating Misconceptions by Encouraging Example-Writing * The Hidden Perils of Automated Assessment * Mystery Languages * Resugaring Type Rules * Picking Colors for Pyret Error Messages * Can We Crowdsource Language Design? * Crowdsourcing User Studies for Formal Methods * User Studies of Principled Model Finder Output * A Third Perspective on Hygiene * Scope Inference, a.k.a. Resugaring Scope Rules * The PerMission Store * Examining the Privacy Decisions Facing Users * The Pyret Programming Language: Why Pyret? * Resugaring Evaluation Sequences * Slimming Languages by Reducing Sugar * In-flow Peer Review: An Overview * Tierless Programming for SDNs: Differential Analysis * Tierless Programming for SDNs: Verification * Tierless Programming for SDNs: Optimality * Tierless Programming for SDNs: Events * Tierless Programming for Software-Defined Networks * CS Student Work/Sleep Habits Revealed As Possibly Dangerously Normal * Parley: User Studies for Syntax Design * Typechecking Uses of the jQuery Language * Verifying Extensions' Compliance with Firefox's Private Browsing Mode * From MOOC Students to Researchers * Social Ratings of Application Permissions (Part 4: The Goal) * Social Ratings of Application Permissions (Part 3: Permissions Within a Domain) * Social Ratings of Application Permissions (Part 2: The Effect of Branding) * Social Ratings of Application Permissions (Part 1: Some Basic Conditions) * Aluminum: Principled Scenario Exploration Through Minimality * A Privacy-Affecting Change in Firefox 20 * The New MOOR's Law * Essentials of Garbage Collection * (Sub)Typing First Class Field Names * Typing First Class Field Names * S5: Engineering Eval * Progressive Types * Modeling DOM Events * Mechanized LambdaJS * ECMA Announces Official lJS Adoption * Objects in Scripting Languages * S5: Wat? * Belay Lessons: Smarter Web Programming * S5: Semantics for Accessors * S5: A Semantics for Today's JavaScript * The Essence of JavaScript * ADsafety Plan Composition Using Higher-Order Functions Posted on 09 July 2022. There is a long history of wanting to examine planning in computing education research, but relatively little work on it. One problem you run into when trying to do this seriously is: "What language shall we use to express plans?" A lot hinges on this language. * The programming language itself is too low-level: there are too many administrative details that get in the way and might distract the student; failures may then reflect these distractions, not an inability to plan. * Plain English may be too high-level. It's both difficult to give any useful (automated) feedback about, it may also require too much interpretation. In particular, an expert may interpret student utterances in ways the student didn't mean, thereby giving the student an OK signal when in fact the student is not on the right path. Separately, in prior work, we looked at whether students are able to understand higher-order functions (HOFs) from a behavioral perspective: i.e., as atomic units of behavior without reference to their underlying implementation. For our population, we found that they generally did quite well. You may now see how these dovetail. Once students have a behavioral understanding of individual HOFs, you can use them as a starting vocabulary for planning. Or to think in more mechanical terms, we want to study how well students understand the composition of HOFs. That is the subject of this work. Concretely, we start by confirming our previous result--that they understand the building blocks--and can also articulate many of the features that we previously handed out to them. This latter step is important because any failures at composition may lie in their insufficiently rich understanding of the functions. Fortunately, we see that this is again not a problem with our population. We then focus on the main question: can they compose these HOFs. We do this in two ways: 1. We give them input-output examples and ask them to identify which compositions of functions would have produced those results. This is akin to having a dataset you need to transform and knowing what you would like the result to look like, and figuring out what steps will take it there. 2. We give them programming problems to solve, and ask them to first provide high-level plans of their solutions. What we find is that students don't do superbly on (1), but do extremely well on (2). Indeed, our goal had been to study what changes between the planning and programming phase (e.g., if they planned incorrectly but programmed correctly; or vice versa), but our students unfortunately did too well on both to give us any useful data! Of particular interest is how we got them to state plans. While HOFs are the "semantics", we still need a "syntax" for writing them. Conventional textual programming has various bad affordances. Instead, we created a custom palette of operations in Snap!. In keeping with the point of this paper, the operations were HOFs. There are numerous advantages to this use of Snap!: * Drag-and-drop construction avoids getting bogged down in the vagaries of textual syntax. * Changing plans is much easier, because you can drag whole blocks and (again) not get caught up in messy textual details. This means students are hopefully more willing to change around their plans. * The planning operations focus on the operations we care about, and students can ignore irrelevant details. * Most subtly: the blanks can be filled in with text. That is, you get "operations on the outside, text on the inside": at the point where things get too detailed, students can focus on presenting their ideas rather than on low-level details. This is, in other words, a hybrid of the two methods we suggested at the beginning. Critically, these aren't programs! Because of the text, they can't be executed. But that's okay! They're only meant to help students think through their plans before starting to write the program. In particular, given students' reluctance to change their programs much once they start coding, it seems especially important to give them a fluid medium--where switching costs are low--in which to plan things before they start to write a line of code. So one of the best things about this paper, beyond the main result, is actually our discovery of Snap!'s likely utility in this setting. For more details, see the paper!