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.

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.

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?