Programmers formulate prompts for code generation based on their understandings of problem domain and LLM ability to execute instructions. A deficiency in either understanding yields inadequate generated code, requiring programmers to revise their understandings based on deficiencies observed in the generated code.

Software development is typically not taught and experienced primarily through books and lectures but instead through practice. However, university teaching entails time constraints, creating a mismatch between the theoretical knowledge from lectures and the practical challenges students face in accompanying projects. Trade-offs of selected practices might not apply, or not apply clearly enough, for students to experience and reflect on them.

Various programming environments feature live programming as a central part of their programming experience. Liveness in these environments is analyzed by several theories, which describe the different forms of liveness and how they influence the programming experience. Unfortunately, these are isolated theories only concerned with live programming features. They can not explain liveness in terms of general interactions with programming tools.One theory that has successfully explained how programmers interact with various kinds of tools is information foraging theory (IFT). In this paper, we propose an IFT interpretation of liveness. By interpreting liveness in terms of a more comprehensive theory of programmer behavior, we can explain the role of liveness in common software development activities such as debugging.We have explored our IFT interpretation of liveness in a first controlled experiment. We investigated the hypothesis that when we remove liveness from live dynamic introspection tools, programmers will use them less often, as using them has a higher cost. We have conducted a post hoc analysis of the results for which we used the edit-run-cycle model adapted to analyze the usage of live programming tools. The post hoc results hint that programmers did shift away from introspection tools. While our study only features post hoc results, it suggests that the IFT interpretation of liveness is a fruitful avenue.

Programmers regularly explore the execution of code examples to verify assumptions by adding print statements or commenting in and out setup code in their implementation to isolate code paths of interest. In our formative study on developing embedded programs, where proximity to hardware dictates low abstraction levels, we observed that wrong assumptions occur frequently. However, traditional editors for embedded programs lack support for such explorations. Consequently, programmers have to re-create and clean up setup and print statements in their code for each example.

As software projects grow increasingly more complex, debloating gains traction. While static analyses yield a coarse over-approximation of reachable code, approaches based on dynamic execution traces risk program correctness. By allowing the developer to reconsider only a few methods and still achieve a significant reduction in code size, cut-based debloating can minimize the risk. In this paper, we propose the idea of finding small cuts in the rule graphs produced by static analysis. After introducing an analysis with suitable semantics, we discuss how to encode its rules into a directed hypergraph. We then present an algorithm for efficiently finding the most effective single cut in the graph. The execution time of the proposed operations allows for the deployment in interactive tools. Finally, we show that our graph model is able to expose methods worthwhile to reconsider.

In exploratory programming, programmers often face a semantic gap between their high-level understanding and the low-level interfaces available for interacting with objects in a system. That is, technical object structure and behavior need to be interpreted as abstract domain concepts, which then increases cognitive load and thus impedes exploration progress. We propose semantic object interfaces that bridge this gap by enabling contextual, natural-language conversations with objects. Our approach leverages an exploratory programming agent powered by a large language model (LLM) to translate natural-language questions into low-level experiments and provide high-level answers. We describe a framework for integrating semantic object interfaces into existing exploratory programming systems, including a prototype implementation in Squeak/Smalltalk using GPT-4o. We showcase the potential of semantic object interfaces through case studies and discuss their feasibility, limitations, and impact on the programming experience. While challenges remain, our approach promises to reduce mental effort and empower programmers to explore and understand systems at a higher level of abstraction for a better programming experience.

We present the architecture-oriented programming language Objective-S, which goes beyond procedure calls for expressing inter-component connectors (so-called glue code) in order to directly express a wide range of architectural patterns directly in the implementation. Previous approaches for encoding architecture require either indirection, maintaining separate architectural descriptions, or both. Expressing the architecture directly in the implementation instead of indirectly avoids the problems associated with creating and maintaining duplicate representations. Objective-S introduces syntactic elements that let us express many architectural connections directly using a simple surface syntax. These surface elements are supported by a metaobject protocol of polymorphic connectors. The key insight of our approach is that while so-called general-purpose programming languages do lack the ability to express most architectural concerns directly, as shown by previous research, this is not an inherent limitation. With Objective-S, we take connectors that already exist in implementation languages, such as data access or procedure calls and make them polymorphic using a metaobject protocol. This metaobject protocol enables polymorphic connection using glue code at the metaobject level that is both generic and mostly hidden from the surface language.

Formal specifications like TLA+ support software developers in formulating and verifying properties of their systems as state machines. Writing specifications helps software developers incrementally develop an understanding of their systems’ domains. However, according to our formative study, while reading such specifications authored by others, software developers tend to struggle to build comprehension. To overcome the limitations of text, participants visualized specifications and manually constructed concrete example sequences of actions. We propose an approach that visualizes state-machine-based specifications to better support software developers in reading, exploring, and understanding them. Our tool, SpecTacles, generates and presents interactive visualizations derived from a specification’s state space next to its original source text. Users can formulate example sequences of actions, which are synchronized between all visualizations. To explore how and why such interactive visualizations help, we conducted a user study ($\mathrm{n}=12$) with software developers who had no prior training in formal specifications, and explored how they use our tool in a set of comprehension tasks. Participants used the source text to obtain local and definitive information, for example, to validate an assumption, but they referred to the visualizations to gain an overview and to compensate for the lack of control flow information in the source text. Given the strengths of both visualizations and source text, participants found SpecTacles useful for their comprehension and indicated that they would like to use it in other software engineering contexts.

Structured editing can show benefits in learnability, tool building, and editing efficiency in programming. However, creating a usable structured editor is laborious and demanding, typically requiring tool builders to manually create or adjust editing interactions.

Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can significantly influence how participants behave. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple.To help researchers deliberately influence task complexity, we discuss different factors of task complexity. We draw these factors from 23 selected and 39 surveyed studies on programming tools. We arrange the factors according to a task complexity model from ergonomics research that we adapt for maintenance tasks. We illustrate the application of the factors through an example critique of a task design. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.

Exploration of state and behavior is essential for understanding and debugging object-oriented programs. Many time-related questions about object communication – an object’s history – only arise in the context of a specific error in the here and now. At such a specific point in time, however, it is often distracting to involve omniscient debugging tools such as program tracers, because they do not integrate well with the programmer’s current focus on space-related questions and the informational cues at hand. In this paper, we present a novel way to provide a tangible, consolidated notion of both space and time in object exploration tools to make it more likely that programmers will use the available means to explore the evolution of particular objects. With programmers remaining informed about and in control of a program’s space and time, we promote the scientific method for debugging and leverage exploratory programming practices. We evaluate our model with hands-on experiences in the Squeak/Smalltalk programming system, using a program tracer that we have integrated into existing exploration tools to promote both spatial and temporal views. We believe that a clear, tangible notion of spacetime can help tool designers provide a better programming experience for those constantly recurring “What happened to this object?” situations.

Debugging is an essential part of software development. Numerous tools and techniques to improve debugging have been proposed in research or developed in the industry. However, only a few of those see widespread use, and debugging only rarely is a primary teaching subject.

Crochet is still purely manual. While other crafts such as knitting or weaving have received technical support, the process of creating instructions for new crochet patterns is barely supported by domain-specific, digital tools. Those tools are constrained by their underlying crochet pattern languages that are either ambiguous or limited in their expressiveness. As a result, creating crochet instructions requires substantial manual effort and can result in incomplete or ambiguous instructions after all.

We must retain liveness and exploratory practices within the programming systems that make us feel most productive. However, the temptation to just reuse black boxes through limited interfaces is pervasive. We expect time savings and better performance at the cost of poor repairability. Fortunately, we also know about the benefits of having an open implementation constructed from familiar materials, integrated with familiar tools. Consequently, it is primarily a matter of “just building it” ... again? Piece of cake. What could possibly go wrong?

Creating structured editors, which maintain a valid syntax tree at all times rather than allowing to edit program text, is typically a time consuming task. Recent work has investigated the use of existing general-purpose language grammars as a basis for automatically generating structured editors, thus considerably reducing the effort required. However, in these generated editors, input occurs through menu and mouse-based interaction, rather than via keyboard entry that is familiar to most users.

Block-based environments are visual programming environments that allow users to program by interactively arranging visual jigsaw-like blocks. They have shown to be helpful in several domains but often require experienced developers for their creation. Previous research investigated the use of language workbenches to generate block-based editors based on grammars, but the generated block-based editors sometimes provided too many unnecessary blocks, leading to verbose environments and programs. To reduce the number of interactions, we propose a set of transformations to simplify the original grammar, yielding a reduction of the number of (useful) kinds of blocks available in the resulting editors. We show that our generated block-based editors are improved for a set of observed aesthetic criteria up to a certain complexity. As such, analyzing and simplifying grammars before generating block-based editors allows us to derive more compact and potentially more usable block-based editors, making reuse of existing grammars through automatic generation feasible.

Game development benefits from short iterations, as it is often concerned with how a game will feel like; something that is hard to anticipate. Live programming aims at reducing the length of iterations during software development to allow for faster exploration and improve program comprehension. We propose a live game development environment providing a more general live programming workflow in game prototyping. The environment supports developers in two aspects: how will a code change affect the look and feel of the game and how does the behavior of the game relate to its code? The proof-of-concept environment ensures short feedback cycles by always keeping the game running while it is being developed. We propose several mechanisms to work with the running game, for example, programmers can automatically replay situations in the game by using an explicit notion of snapshots. We tentatively demonstrate the effectiveness of the live programming features in the context of the development of game prototypes of different genres.

The software engineering practice of automated testing helps programmers find defects earlier during development. With growing software projects and longer-running test suites, frequency and immediacy of feedback decline, thereby making defects harder to repair. Regression test prioritization (RTP) is concerned with running relevant tests earlier to lower the costs of defect localization and to improve feedback.

There are many factors for the success of a new programming language implementation. Existing language implementation frameworks such as Truffle or RPython have focused on run-time performance and security, or on providing a comprehensive set of libraries.

We propose standard object out, an object-oriented analog to the output part of the Unix standard input output library.

Polyglot programming provides software developers with a broader choice in terms of software libraries and frameworks available for building applications. Previous research and engineering activities have focused on language interoperability and the design and implementation of fast polyglot runtimes. To make polyglot programming more approachable for developers, novel software development tools are needed that help them build polyglot applications. We believe a suitable prototyping platform helps to more quickly evaluate new ideas for such tools. In this paper we present GraalSqueak, a Squeak/Smalltalk virtual machine implementation for the GraalVM. We report our experience implementing GraalSqueak, evaluate the performance of the language and the programming environment, and discuss how the system can be used as a tooling platform for polyglot programming.

Storage strategies have been proposed as a run-time optimization for the PyPy Python implementation and have shown promising results for optimizing execution speed and memory requirements. However, it remained unclear whether the approach works equally well in other dynamic languages. Furthermore, while PyPy is based on RPython, a language to write VMs with reusable components such as a tracing just-in-time compiler and garbage collection, the strategies design itself was not generalized to be reusable across languages implemented using that same toolchain. In this paper, we present a general design and implementation for storage strategies and show how they can be reused across different RPython-based languages. We evaluate the performance of our implementation for RSqueak, an RPython-based VM for Squeak/Smalltalk and show that storage strategies may indeed offer performance benefits for certain workloads in other dynamic programming languages.We furthermore evaluate the generality of our implementation by applying it to Topaz, a Ruby VM, and Pycket, a Racket implementation.

We present Pycket, a high-performance tracing JIT compiler for Racket. Pycket supports a wide variety of the sophisticated features in Racket such as contracts, continuations, classes, structures, dynamic binding, and more. On average, over a standard suite of benchmarks, Pycket outperforms existing compilers, both Racket's JIT and other highly-optimizing Scheme compilers. Further, Pycket provides much better performance for Racket proxies than existing systems, dramatically reducing the overhead of contracts and gradual typing. We validate this claim with performance evaluation on multiple existing benchmark suites. The Pycket implementation is of independent interest as an application of the RPython meta-tracing framework (originally created for PyPy), which automatically generates tracing JIT compilers from interpreters. Prior work on meta-tracing focuses on bytecode interpreters, whereas Pycket is a high-level interpreter based on the CEK abstract machine and operates directly on abstract syntax trees. Pycket supports proper tail calls and first-class continuations. In the setting of a functional language, where recursion and higher-order functions are more prevalent than explicit loops, the most significant performance challenge for a tracing JIT is identifying which control flows constitute a loop---we discuss two strategies for identifying loops and measure their impact.

Object-constraint programming systems integrate declarative constraint solving with imperative, object-oriented languages, seamlessly providing the power of both paradigms. However, experience with object-constraint systems has shown that giving too much power to the constraint solver opens up the potential for solutions that are surprising and unintended as well as for complex interactions between constraints and imperative code. On the other hand, systems that overly limit the power of the solver, for example by disallowing constraints involving mutable objects, object identity, or polymorphic message sends, run the risk of excluding the core object-oriented features of the language from the constraint part, and consequently not being able to express declaratively a large set of interesting problem solutions. In this paper we present design principles that tame the power of the constraint solver in object-constraint languages to avoid difficult corner cases and surprising solutions while retaining the key features of the approach, including constraints over mutable objects, constraints involving object identity, and constraints on the results of message sends. We present our solution concretely in the context of the Babelsberg object-constraint language framework, providing both an informal description of the resulting language and a formal semantics for a core subset of it. We validate the utility of this semantics with an executable version that allows us to run test programs and to verify that they provide the same results as existing implementations of Babelsberg in JavaScript, Ruby, and Smalltalk.

We report our experience in implementing SqueakJS, a bit-compatible implementation of Squeak/Smalltalk written in pure JavaScript. SqueakJS runs entirely in the Web browser with a virtual filesystem that can be directed to a server or client-side storage. Our implementation is notable for simplicity and performance gained through adaptation to the host object memory and deployment leverage gained through the Lively Web development environment. We present several novel techniques as well as performance measurements for the resulting virtual machine. Much of this experience is potentially relevant to preserving other dynamic language systems and making them available in a browser-based environment.

We present object versioning as a generic approach to preserve access to previous development and application states. Version-aware references can manage the modifications made to the target object and record versions as desired. Such references can be provided without modifications to the virtual machine. We used proxies to implement the proposed concepts and demonstrate the Lively Kernel running on top of this object versioning layer. This enables Lively users to undo the effects of direct manipulation and other programming actions.

In object-oriented programming, polymorphic dispatch of operations decouples clients from specific providers of services and allows implementations to be modified or substituted without affecting clients.

Self-supporting development environments like Smalltalk and Emacs can be used to directly evolve themselves, making their tools very malleable and adaptable. In Web-based software development environments users can collaborate in creating software without having to install the environment locally. Bringing these two together and making Web-based environments self-supportive is challenging, since users have to take care of to breaking the system, since there might be others using it also. Environments aimed at end-users usually provide a scripting level above the base system. Instead of providing users with a fixed set of tools, we propose to make the tools user-evolvable by building them as scriptable objects in a shared user editable repository. In our system, the Lively Kernel, the core system is developed using modules and classes, and on top of it users create active content by directly manipulating and scripting objects. By leveraging the scripting level for the development of tools themselves, we allow users to adapt their tools in a self-supporting way, without the need to invasively change the system's core. In this paper we show how development tools in Lively are collaboratively evolved. Tools can be directly explored, adapted, and published in a shared manner while they are being used.

Programmers make many changes to the program to eventually find a good solution for a given task. In this course of change, every intermediate development state can of value, when, for example, a promising ideas suddenly turn out inappropriate or the interplay of objects turns out more complex than initially expected before making changes. Programmers would benefit from tool support that provides immediate access to source code and run-time of previous development states of interest. We present IDE extensions, implemented for Squeak/Smalltalk, to preserve, retrieve, and work with this information. With such tool support, programmers can work without worries because they can rely on tools that help them with whatever their explorations will reveal. They no longer have to follow certain best practices only to avoid undesired consequences of hanging code.

Use-cases are considered an integral part of most contemporary development processes since they describe a software system's expected behavior from the perspective of its prospective users. However, the presence of and traceability to use-cases is increasingly lost in later more code-centric development activities. Use-cases, being well-encapsulated at the level of requirements descriptions, eventually lead to crosscutting concerns in system design and source code. Tracing which parts of the system contribute to which use-cases is therefore hard and so limits understandability.

This paper introduces the SOM (Simple Object Machine) family of virtual machine (VM) implementations, a collection of VMs for the same Smalltalk dialect addressing students at different levels of expertise. Starting from a Java-based implementation, several ports of the VM to different programming languages have been developed and put to successful use in teaching at both undergraduate and graduate levels since 2006. Moreover, the VMs have been used in various research projects. The paper documents the rationale behind each of the SOM VMs and results that have been achieved in teaching and research.

Teaching pupils the ideas behind objects in programming languages can be difficult since these concepts are mostly abstract and not comprehensible at first sight. Etoys as a visual programming environment counters such issues by introducing visible objects and simple tiles for programming them. However, all of these objects can only be experienced virtually on the screen. This paper presents PhidgetLab, a programming environment for electronic components (Phidgets) realised on top of the Etoys environment. PhidgetLab helps crossing the border from virtual to real-world objects. Pupils interact with tangible objects that are seamlessly connected to the digital world. PhidgetLab was evaluated in a case study with 22 pupils, following the principles of the Design Thinking methodology and comprised the realisation of five prototypes within a short period of time.

Combining support for single display collaboration with support for asynchronous and remote collaboration in one groupware challenges some basic assumptions of application design and brings up new requirements for application platforms. While user accounts are central in many kinds of groupware, the

We describe semantic mappings of four high-level programming languages to our delegation-based machine model for aspect-oriented programming. One of the languages is a class-based object-oriented one. The other three represent extensions thereof that support various approaches to modularizing crosscutting concerns. We explain informally that an operational semantics expressed in terms of the model's concepts preserves the behavior of a program written in one of the high-level languages. We hence argue our model to be semantically sound in that sense, as well as sufficiently expressive in order to correctly support features such as class-based object-oriented programming, the open-classes and pointcut-and-advice flavors of aspect-oriented programming, and dynamic layers. For the latter, being a core feature of context-oriented programming, we also provide a formal semantics.

Abstract Change can be observed in our environment and in the technology we build. While changes in the environment happen continuously and implicitly, our technology has to be kept in sync with the changing world around it. Although we can prepare for some of the changes for most of them we cannot. This is especially true for next‐generation mobile communication systems that are expected to support the creation of a ubiquitous society where virtually everything is connected and made available within an organic information network. Resources will frequently join or leave the network, new types of media or new combinations of existing types will be used to interact and cooperate, and services will be tailored to preferences and needs of individual customers to better meet their needs. This paper outlines our research in the area of dynamic service adaptation to provide concepts and technologies allowing for such environments. Copyright © 2006 John Wiley & Sons, Ltd.

ContextL is an extension to the Common Lisp Object System that allows for Context-oriented Programming. It provides means to associate partial class and method definitions with layers and to activate and deactivate such layers in the control flow of a running program. When a layer is activated, the partial definitions become part of the program until this layer is deactivated. This has the effect that the behavior of a program can be modified according to the context of its use without the need to mention such context dependencies in the affected base program. We illustrate these ideas by providing different UI views on the same object while, at the same time, keeping the conceptual simplicity of object-oriented programming that objects know by themselves how to behave, in our case how to display themselves. These seemingly contradictory goals can be achieved by separating class definitions into distinct layers instead of factoring out the display code into different classes.