Search

A thorough understanding of specified behavior is essential for the completion of most programming tasks. Researchers have created automated tools to help students with this task. Yet, even with automated feedback, students may still face self-insurmountable challenges for which they must seek aid from the course staff. What self-insurmountable challenges do students face? And (how) does access to automatic, on-demand feedback shape student help-seeking? To find out, we manually reviewed the 1,247 assignment-related student posts in the online help-forum of a post-secondary accelerated introductory computer science course. We report on the high-level relationships between student help-seeking and (under)specification in assignments, and identify a number of behaviors relevant to both researchers and educators.

Motivation. “Adversarial thinking” (at) is viewed as a central idea in cybersecurity. We believe a similar idea carries over into other critical areas as well, such as understanding the perils of social networks and machine learning. Objectives. What kinds of at can we expect of early post-secondary computing students? In particular, can they meaningfully analyze computing systems that are well beyond their technical ken? Is their analysis limited to only a social or only a technical space? Method. In an introductory post-secondary course, we study student responses to questions designed to exercise at, broadly defined. To do this we develop a rubric that provides insight into desirable content. Results. We find that these students are fairly strong at at. They are regularly able to adopt an adversarial or empathetic viewpoint and analyze quite sophisticated systems. Most of all, they can meaningfully do so (a) outside an explicit cybersecurity context, (b) even from an introductory level, and (c) well before they understand well the key technologies under evaluation. On the other hand, we also find several instances where students do not explore systems as much as they could, and fail to reference other material they know, which could be evidence of lack of transfer. In addition, our rubric would benefit from refinement that would enable a more sophisticated analysis of student responses. Discussion. Our work provides a baseline evaluation of what we can expect from students. It suggests that at can be introduced early in the curriculum, and in contexts outside computer security.

Motivation. Higher-order functions are a standard and increasingly central component in many kinds of modern programming, including data science and Web development. Yet little research has been devoted to student learning or understanding of this topic. Objectives. We conducted formative research on how well students are able to correlate higher-order functions with their input–output behavior. We also wanted to evaluate a variety of techniques for assessing their understanding. Method. We created a series of instruments in which students were given either concrete input/output examples or abstracted diagrams of list transformations. Students were asked to cluster or classify these examples by their behavior, sometimes against a concrete list of higher-order functions and sometimes free-form. We administered these over the course of a month, and then once again three months later. Results. We find that students initially have several difficulties with clustering higher-order function examples. With different instruments, we find that students are later able to do quite well, largely avoiding large-scale errors but making several small-scale ones. We also find some evidence of growth in their thinking about these operations. We also find weaknesses in the nature and order of techniques we used. Discussion. Higher-order functions deserve far more attention than they have been paid in the literature on programming education. Their increasing use in several important domains makes this need critical. Our proposed methods for conducting such research are another contribution of this work. Our findings and methods should also be relevant for exploring how students understand libraries and APIs.

Integrating computing into other subjects promises to address many challenges to offering standalone CS courses in K-12 contexts. Integrated curricula must be designed carefully, however, to both meet learning objectives of the host discipline and to gain traction with teachers. We describe the multi-year evolution of Bootstrap, a curriculum for integrating computing into middle- and high-school mathematics. We discuss the initial design and the various modifications we have made over the years to better support math instruction, leading to our goal of using integrated curricula to cover standards in both math and CS. We provide advice for others aiming for integration and raise questions for CS educators about how we might better support learning in other disciplines.

What does it take to adapt a programming environment so students with low or no vision can comfortably use it? Every aspect of the environment needs attention, from toolbars to editors to interactive components. We describe the steps we had to take to adapt WeScheme, the environment used by Bootstrap:Algebra. We also summarize the experience of a group of blind students using the result, and present some lessons for other curricula to consider. A particular challenge in Bootstrap:Algebra is its heavy reliance on images, which many other media-rich curricula also use. Visual computing is, almost by definition, inaccessible to students with low or poor vision. This poses curricular, legal, and moral obstacles for computing educators who want to use these curricula.

Students faced with a programming task often begin their implementation without a sufficient understanding of the problem. Several prior papers suggest that formulating input–output examples before beginning one’s implementation is the key to averting problem misunderstandings, but that students are loath to actually do it. Is outright coercion instructors’ only hope to convince students to follow this methodology and hence help themselves? We conjecture that students’ reluctance may stem from the disaffordances of their programming environments. In this work, we augment the student’s programming environment to encourage examples-first development, and design a novel measure to assess students’ adherence to this methodology. We apply these measures to students using our modified environment in a semester-long course, and find high voluntary adherence, especially relative to the literature’s low expectations.

Configuring a service mesh often involves multiple parties, each of whom is responsible for separate portions of the overall system. This can result in miscommunication, silent and sudden errors, or a failure to meet goals. We identify two distinct modes of configuration that call for different solutions. We use synthesis algorithms to extract a set of properties---the envelope ---that each party needs the other to obey. Administrators can use the envelope to aid verification and synthesis or to support fault-localization and negotiation when goals conflict. This paper introduces the problem, lays out the modes, presents algorithms for to each, and gives a prototype implementation. We use this to show the feasibility of the approach in the microservices access-control domain and raise new research questions.

Data that correspond to real-world scenarios can often be organized in several different ways in a database or program. Appreciating the differences between them and choosing an organization that addresses a system's needs are valuable and necessary computing skills. Unfortunately, little of the computing-education literature seems to deal with this topic. In this paper we consider a technique for getting students to engage with this issue, grounded in theories of examples and differences. Instead of presenting a single organization, we present a pair of organizations and ask students to contrast them. Students then interact directly with the two organizations in a reflection step, which is followed by a further round of contrasting. Our data show that even novice college students can handle this task fairly well. They are able to find many crucial differences (especially in terms of access and update operations), but also miss some (especially performance and privacy). These data suggest that this is a useful technique to pursue further, and also point to areas where students may need more instructional support.

In many universities, Teaching Assistants (TAs) are an important part of students' educational experience. This is especially true in early courses, where students may suffer from inexperience and anxiety, and find fellow students more accessible than professors.Despite its importance, this learning channel has not been studied very much. Part of the difficulty lies in how to meaningfully evaluate it. Any intervention needs to be both unintrusive and lightweight, and yet yield useful data. As a result, to many faculty and researchers, TA office hours remain fairly opaque.This paper presents one approach to studying the technical component (but not the social dynamics) of TA office hours. We use a program-design methodology as a device to help track what students are asking about in hours, using a simple survey-based method to gather data. Data from TAs effectively summarize students' questions. In addition, contrasting data from both TAs and students provides insight into students' progress on program design help-seeking over the course of the semester.

Flawed problem comprehension leads students to produce flawed implementations. However, testing alone is inadequate for checking comprehension: if a student develops both their tests and implementation with the same misunderstanding, running their tests against their implementation will not reveal the issue. As a solution, some pedagogies encourage the creation of input-output examples independent of testing-but seldom provide students with any mechanism to check that their examples are correct and thorough.We propose a mechanism that provides students with instant feedback on their examples, independent of their implementation progress. We assess the impact of such an interface on an introductory programming course and find several positive impacts, some more neutral outcomes, and no identified negative effects.

Generating questions to engage and measure students is often challenging and time-consuming. Furthermore, these questions do not always transfer well between student populations due to differences in background, course emphasis, or ambiguity in the questions or answers. We introduce a contributing student pedagogy activity facilitated by machine learning that can generate questions with associated answer-reasoning sets. We call this process Adaptive Tool-Driven Conception Generation. A tool implementing this process has been deployed, and it explicitly optimizes the process for questions that divide student opinion. In a study involving arrays in Java, this novel process: generates questions similar to expert-designed questions, produces novel questions that identify potential student misconceptions, and provides statistical estimates of the prevalence of misconceptions. This process allows the generation of quiz and discussion questions with less expert effort, facilitates a subprocess in the creation of concept inventories, and also raises the possibility of running reproduction studies relatively cheaply.

Most programmers rely on visual tools (block-based editors, auto-indentation, bracket matching, syntax highlighting, etc.), which are inaccessible to visually-impaired programmers. While prior language-specific, downloadable tools have demonstrated benefits for the visually-impaired, we lack language-independent, cloud-based tools, both of which are critically needed. We present a new toolkit for building fully-accessible, browser-based programming environments for multiple languages. Given a parser that meets certain specifications, this toolkit will generate a block editor familiar to sighted users that also communicates the structure of a program using spoken descriptions, and allows for navigation using standard (accessible) keyboard shortcuts. This paper presents the toolkit and a first evaluation of it. While the toolkit allows for full editing of code, we chose to focus strictly on navigation for this evaluation, using the navigation-only study design of Baker, Milne and Ladner. Visually-impaired programmers completed several tasks with and without our tool, and we compared their results and experience. Users had improved accuracy when completing tasks, were significantly better able to orient when reading code, and felt better about completing the tasks when using the tool. Moreover, these improvements came with no significant change in task completion time over plain text, even for experienced programmers who navigate text using screen readers set to high words-per-minutes.

Instructors routinely use automated assessment methods to evaluate the semantic qualities of student implementations and, sometimes, test suites. In this work, we distill a variety of automated assessment methods in the literature down to a pair of assessment models. We identify pathological assessment outcomes in each model that point to underlying methodological flaws. These theoretical flaws broadly threaten the validity of the techniques, and we actually observe them in multiple assignments of an introductory programming course. We propose adjustments that remedy these flaws and then demonstrate, on these same assignments, that our interventions improve the accuracy of assessment. We believe that with these adjustments, instructors can greatly improve the accuracy of automated assessment.

Bootstrap:Algebra is a curricular module designed to integrate introductory computing into an algebra class; the module aims to help students improve on various essential learning outcomes from state and national algebra standards. In prior work, we published initial findings about student performance gains on algebra problems after taking Bootstrap. While the results were promising, the dataset was not large, and had students working on algebra problems that had been scaffolded with Bootstrap's pedagogy. This paper reports on a more detailed study with (a) data from more than three times as many students, (b) analysis of performance changes in incorrect answers, (c) some problems in which the Bootstrap scaffolds have been removed, and (d) an IRT analysis across the elements of Bootstrap's program-design pedagogy. Our results confirm that students improve on algebraic word problems after completing the module, even on unscaffolded problems. The nature of incorrect answers to symbolic-form questions also appears to improve after Bootstrap.

We evaluate a notional machine for recursion based on algebraic substitution. To do this, we decompose recursion into a progression of function call patterns, parameter name reuse, and data structure complexity. At each stage, we test students' ability to trace programs using substitution. We evaluate the correctness of their traces along multiple dimensions, finding that students generally do well, and also observe shortcuts and identify misconceptions. For comparison, we also have students trace two problems using a traditional, imperative notional machine. Even though the substitution model is unwieldy to use with compound data, students still perform better with it than with the traditional notional machine.

Game programming projects are concrete and motivational for students, especially when used to teach more abstract concepts such as algebra. These projects must have open-ended elements to allow for creativity, but too much freedom makes it hard to reach specific learning outcomes. How many degrees of freedom do students need to make a game feel like one they genuinely designed? What kinds of personalization do they undertake of their games? And how do these factors correlate with their prior game-playing experience or with their identified gender? This paper studies these questions in the concrete setting of the Bootstrap:Algebra curriculum. In this curriculum, students are only given four parameters they can customize and only a few minutes in which to do so. Our study shows that despite this very limited personalization, students still feel a strong sense of ownership, originality, and pride in their creations. We also find that females find videogame creation just as satisfying as males, which contradicts some prior research but may also reflect the nature of games created in this curriculum and the opportunities it offers for self-expression.

Data Science is at the center of many current curricular efforts. It is emerging as an integrated field that has far-reaching and important applications, from news media to policy making to business. While these applications can provide compelling uses of computer science techniques, an introduction to one is not an introduction to the other. How do topics like data structures and program design emerge from data science applications? How do we transition from data science applications to computer science topics? How can data science be integrated into other contexts with little overhead? This workshop presents assignments and curricula designed to answer these questions, and tools that support them.

Most programming problems have multiple viable solutions that organize the underlying problem's tasks in fundamentally different ways. Which organizations (a.k.a. plans) students implement and prefer depends on solutions they have seen before as well as features of their programming language. How much exposure to planning do students need before they can appreciate and produce different plans? We report on a study in which students in introductory courses at two universities were given a single lecture on planning between assessments. In the post-assessment, many students produced multiple high-level plans (including ones first introduced in the lecture) and richly discussed tradeoffs between plans. This suggests that planning can be taught with fairly low overhead once students have a decent foundation in programming.

This paper presents a lightweight process to guide error report authoring. We take the perspective that error reports are really classifiers of program information. They should therefore be subjected to the same measures as other classifiers (e.g., precision and recall). We formalize this perspective as a process for assessing error reports, describe our application of this process to an actual programming language, and present a preliminary study on the utility of the resulting error reports.

Most programming languages have been designed by committees or individuals. What happens if, instead, we throw open the design process and let lots of programmers weigh in on semantic choices? Will they avoid well-known mistakes like dynamic scope? What do they expect of aliasing? What kind of overloading behavior will they choose? We investigate this issue by posing questions to programmers on Amazon Mechanical Turk. We examine several language features, in each case using multiple-choice questions to explore programmer preferences. We check the responses for consensus (agreement between people) and consistency (agreement across responses from one person). In general we find low consistency and consensus, potential confusion over mainstream features, and arguably poor design choices. In short, this preliminary evidence does not argue in favor of designing languages based on programmer preference.

Scenario-finding tools like the Alloy Analyzer are widely used in numerous concrete domains like security, network analysis, UML analysis, and so on. They can help to verify properties and, more generally, aid in exploring a system's behavior. While scenario finders are valuable for their ability to produce concrete examples, individual scenarios only give insight into what is possible, leaving the user to make their own conclusions about what might be necessary. This paper enriches scenario finding by allowing users to ask ``why?'' and ``why not?'' questions about the examples they are given. We show how to distinguish parts of an example that cannot be consistently removed (or changed) from those that merely reflect underconstraint in the specification. In the former case we show how to determine which elements of the specification and which other components of the example together explain the presence of such facts. This paper formalizes the act of computing provenance in scenario-finding. We present Amalgam, an extension of the popular Alloy scenario-finder, which implements these foundations and provides interactive exploration of examples. We also evaluate Amalgam's algorithmics on a variety of both textbook and real-world examples.

Scope, aliasing, mutation, and parameter passing are fundamental programming concepts that interact in subtle ways, especially in complex programs. Research has shown that students have substantial misconceptions on these topics. But this research has been done largely in CS1 courses, when students' programming experience is limited and problems are necessarily simple. What happens later in the curriculum? Does more programming experience iron out these misconceptions naturally, or are interventions required? This paper explores students' understanding of these topics in the context of a programming languages class for third- and fourth-year CS majors. Our pre- and post-tests pose questions in two programming languages to gauge whether upper-level students transfer knowledge between languages. Many students held misconceptions about these concepts at the start of the course. Students made progress in only some languages and topics, and cross-language transfer does not occur naturally. We also discuss various pedagogic activities we used to engage students with these concepts, and provide data and student opinion on their effectiveness.

Testing and debugging networks /in situ/ is notoriously difficult. Many vital correctness properties involve histories over multiple packets (e.g., prior established connections). Checking such properties requires /cross-packet state/, which cannot be fully captured on stateless switch hardware.Recent SDN work is enabling limited switch operations on persistent state. We present runtime checking of cross-packet correctness properties as a unique and instructive use case for developing stateful switch primitives. In this paper, we examine a set of cross-packet properties and distill from them switch features needed to monitor their correctness. We then contrast these against features provided by current approaches to switch state in SDNs and identify semantic gaps with an eye toward informing future switch instruction sets.

App-based systems are typically supported by marketplaces that provide easy discovery and installation of third-party apps. To mitigate risks to user privacy, many app systems use permissions to control apps' access to user data. It then falls to users to decide which apps to install and how to manage their permissions, which many users lack the expertise to do in a meaningful way. Marketplaces are ideally positioned to inform users about privacy, but they do not take advantage of this. This lack of privacy guidance makes it difficult for users to make informed privacy decisions. We present both an app marketplace and a permission management assistant that incorporate privacy information as a key element, in the form of permission ratings. We discuss gathering this rating information from both human and automated sources, presenting the ratings in a way that users can understand, and using this information to promote privacy-respecting apps and help users manage permissions.

Plan composition is an important but under-studied topic in programming education. Most studies were done three decades ago, under assumptions that miss important issues that today's students must confront. This paper presents rationale and details for a modernized study of plan composition that accommodates a broader range of programming languages and problem features. Our study design has two novelties: the problems require students to deal with data-processing challenges (such as noisy data), and the questions ask students to not only produce but also evaluate programs. We present preliminary results from using our study in multiple courses from different linguistic paradigms. We discuss several future studies that are prompted by these results.

In in-flow peer review, students provide feedback to one another on intermediate artifacts on their way to a final submission. Prior work has studied examples and tests as a potentially useful initial artifact for review. Unfortunately, large test suites are onerous to produce and especially to review. We instead propose the notion of a sweep, an artificially constrained set of tests that illustrates common and interesting behavior. We present experimental data across several courses that show that sweeps have reasonable quality, and are also a good target for peer review; for example, students usually (over half the time) suggest new tests to one another in a review.

Splitting a language into a core language and a desugaring function makes it possible to produce tractable semantics for real-world languages. It does so by pushing much of the language's complexity into desugaring. This, however, produces large and unwieldy core programs, which has proven to be a significant obstacle to actual use of these semantics. In this paper we analyze this problem for a semantics of JavaScript. We show that much of the bloat is *semantic bloat*: a consequence of the language's rich semantics. We demonstrate how assumptions about language use can confine this bloat, and codify these through several transformations that, in general, do not preserve the language's semantics. We experimentally demonstrate the effectiveness of these transformations. Finally, we discuss the implications of this work on language design and structure.

Modern network software is implemented across two tiers: the data plane, which contains packet-processing rules implemented efficiently on switching hardware, and the control plane, which implements fundamental algorithms, policies, and business rules that determine what the data plane should do. Thus, programming the network is akin to programming a two-tier, massively distributed system, where each node has heterogeneous processing capabilities. In addition, the persistent store on the controller represents a third tier. This splitting across tiers leads to both correctness and performance errors.In response, we have designed a language, Flowlog, for programming networks in a "tierless" way that unifies descriptions of control, data, and external state. Tierless programming not only simplifies programming but also makes it easier to express and reason about invariants that cross-cut tiers. In this talk I will discuss applications of Flowlog to both Software-Defined Networking and programming Internet of Things networks. I will also discuss a variety of analysis tasks.This talk describes joint work with Tim Nelson, Andrew Ferguson, Michael Scheer, and Rodrigo Fonseca.

Although Software-Defined Networking can simplify network management, it also poses new testing and debugging challenges for operators. Debugging is often an interactive process that involves stepping through data- and control-plane events and performing actions in response. Sometimes, however, this interactive process can become highly repetitive; in such cases, we should be able to script the activity to reduce operator overhead and increase reusability.We introduce Simon, a Scriptable Interactive Monitoring system for SDN. With Simon, operators can probe their network behavior by executing scripts for debugging, monitoring, and more. Simon is independent of the controller platform used, and does not require annotations or intimate knowledge of the controller software being run. Operators may compose debugging scripts both offline and interactively at Simon's debugging prompt. In the process, they can take advantage of the rich set of reactive functions Simon provides as well as the full power of Scala. We present the design of Simon and discuss its implementation and use.

We present the design and a prototype of Exodus, a system that consumes a collection of router configurations (e.g., in Cisco IOS), compiles these into a common, intermediate semantic form, and then produces corresponding SDN controller software in a high-level language. Exodus generates networks that are functionally similar to the original networks, with the advantage of having centralized programs that are verifiable and evolvable. Exodus supports a wide array of IOS features, including non-trivial kinds of packet-filtering, reflexive access-lists, NAT, VLANs, static and dynamic routing. Implementing Exodus has exposed several limitations in both today's languages for SDN programming and in OpenFlow itself. We briefly discuss these lessons learned and provide guidance for future SDN migration efforts.

Many educators have tried to leverage computing or programming to help improve students' achievement in mathematics. However, several hopes of performance gains---particularly in algebra---have come up short. In part, these efforts fail to align the computing and mathematical concepts at the level of detail typically required to achieve transfer of learning. This paper describes Bootstrap, an early-programming curriculum that is designed to teach key algebra topics as students build their own videogames. We discuss the curriculum, explain how it aligns with algebra, and present initial data showing student performance gains on standard algebra problems after completing Bootstrap.

Desugaring, a key form of program manipulation, is a vital tool in the practical study of programming languages. Its use enables pragmatic solutions to the messy problems of dealing with real languages, but it also introduces problems that need addressing. By listing some of these challenges, this paper and talk aim to serve as a call to arms to the community to give the topic more attention.

Test-first development and peer review have been studied independently in computing courses, but their combination has not. We report on an experiment in which students in two courses conducted peer review of test suites while assignments were in progress. We find strong correlation between review ratings and staff-assessed work quality, as well as evidence that test suites improved during the review process. Student feedback suggests that reviewing had some causal impact on these improvements. We describe several lessons learned about administering and assessing peer-review within test-first development.

The privacy policies of many websites, especially those designed for sharing data, are a product of many inputs. They are defined by the program underlying the website, by user configurations (such as privacy settings), and by the interactions that interfaces enable with the site. A website's security thus depends partly on users' ability to effectively use security mechanisms provided through the interface.Questions about the effectiveness of an interface are typically left to manual evaluation by user-experience experts. However, interfaces are generated by programs and user input is received and processed by programs. This suggests that aspects of usable security could also be approached as a program-analysis problem.This paper establishes a foundation on which to build formal analyses for usable security. We define a formal model for data-sharing websites. We adapt a set of design principles for usable security to modern websites and formalize them with respect to our model. In the formalization, we decompose each principle into two parts: one amenable to formal analysis, and another that requires manual evaluation by a designer. We demonstrate the potential of this approach through a preliminary analysis of models of actual sites.

A new trend in software engineering and programming language conferences is to investigate the reproducibility of research results. This trend has led to the creation of Artifact Evaluation Committees at several conferences, including OOPSLA this year. What is the motive behind these committees? How should they be structured? Do they help? Can they hurt? And should software be given more respect, at least at conferences devoted to the study of software, or should papers remain supreme? These are some of the questions that addressed in this panel. Shriram Krishanamurthi argues in favor of the new process and James Noble plays devil's advocate. The panel is moderated by Jan Vitek.

Configuration languages for traditional network hardware are often fairly limited and hence easy to analyze. Programmable controllers for software-defined networks are far more flexible, but this flexibility results in more opportunities for mis-configuration and greatly complicates analyses. We propose a new network-programming paradigm that strikes a balance between expressive power and analysis, providing a highly analyzable core language while allowing the re-use of pre-existing code written in more complex production languages.As the first step we have created FlowLog, a declarative language for programming SDN controllers. We show that FlowLog is expressive enough to build some real controller programs. It is also a finite-state language, and thus amenable to many types of analysis, such as model-checking. In this paper we present FlowLog, show examples of controller programs, and discuss analyzing them.

Given the widespread use of memory-safe languages, students must understand garbage collection well. Following a constructivist philosophy, an effective approach would be to have them implement garbage collectors. Unfortunately, a full implementation depends on substantial knowledge of compilers and runtime systems, which many courses do not cover or cannot assume.This paper presents an instructive approach to teaching GC, where students implement it atop a simplified stack and heap. Our approach eliminates enormous curricular dependencies while preserving the essence of GC algorithms. We take pains to enable testability, comprehensibility, and facilitates debugging. Our approach has been successfully classroom-tested for several years at several institutions.

As modern type systems grow ever-richer, it can become increasingly onerous for programmers to satisfy them. However, some programs may not require the full power of the type system, while others may wish to obtain these rich guarantees incrementally. In particular, programmers may be willing to exploit the safety checks of the underlying runtime system as a substitute for some static guarantees. Progressive types give programmers this freedom, thus creating a gentler and more flexible environment for using powerful type checkers. In this paper we discuss the idea, motivate it with concrete, real-world scenarios, then show the development of a simple progressive type system and present its (progressive) soundness theorem.

Hierarchical policies are useful in many contexts in which resources are shared among multiple entities. Such policies can easily express the delegation of authority and the resolution of conflicts, which arise naturally when decision-making is decentralized. Conceptually, a hierarchical policy could be used to manage network resources, but commodity switches, which match packets using flow tables, do not realize hierarchies directly.This paper presents Hierarchical Flow Tables (HFT), a framework for specifying and realizing hierarchical policies in software defined networks. HFT policies are organized as trees, where each component of the tree can independently determine the action to take on each packet. When independent parts of the tree arrive at conflicting decisions, HFT resolves conflicts with user-defined conflict-resolution operators, which exist at each node of the tree. We present a compiler that realizes HFT policies on a distributed network of OpenFlow switches, and prove its correctness using the Coq proof assistant. We then evaluate the use of HFT to improve performance of networked applications.

The prevalence of threats and attacks in modern systems demands programming techniques that help developers maintain security and privacy. In particular, frameworks for composing components written by multiple parties must enable the authors of each component to erect safeguards against intrusion by other components. Object-capability systems have been particularly prominent for enabling encapsulation in such contexts.We describe the program structures dictated by object capabilities and compare these against those that ensue from feature-oriented programming. We argue that the scalability offered by the latter appears to clash with the precision of authority designation demanded by the former. In addition to presenting this position from first principles, we illustrate it with a case study. We then offer a vision of how this conflict might be reconciled, and discuss some of the issues that need to be considered in bridging this mismatch. Our findings suggest a significant avenue for research at the intersection of software engineering and security.

Error messages are one of the most important tools that a language offers its programmers. For novices, this feed-back is especially critical. Error messages typically contain both a textual description of the problem and an indication of where in the code the error occurred. This paper reports on a series of studies that explore beginning students' inter-actions with the vocabulary and source-expression high-lighting in DrRacket. Our findings demonstrate that the error message significantly fail to convey information accurately to students, while also suggesting alternative designs that might address these problems.

We posit that functional programmers employ a notion called expression integrity to understand programs. We attempt to study the extent to which both novices and experts use this notion as they program, discuss the difficulties that arise in measuring this, and offer some observational findings.

We present a programming environment called WeScheme that runs in the Web browser and supports interactive development. WeScheme programmers can save programs directly on the Web, making them accessible from everywhere. As a result, sharing of programs is a central focus that WeScheme supports seamlessly. The environment also leverages the existing presentation media and program run-time support found in Web browsers, thus making these easily accessible to students and leveraging their rapid engineering improvements. WeScheme is being used successfully by students, and is especially valuable in schools that have prohibitions on installing new software or lack the computational demands of more intensive programming environments.

We performed a study of Facebook users to examine how they coped with limitations of the Facebook privacy settings interface. Students graduating and joining the workforce create significant problems for all but the most basic privacy settings on social networking websites. We therefore created realistic scenarios exploiting work/play boundaries that required users to specify access control policies that were impossible due to various limitations. We examined whether users were aware of these problems without being prompted, and once given feedback, what their coping strategies were. Overall, we found that simply alerting participants to potential errors was ineffective, but when choices were also presented, participants introduced significantly fewer errors. Based on our findings, we designed a privacy settings interface based on Venn diagrams, which we validated with a usability study. We conclude that this interface may be more effective than the current privacy settings interface.