Reflection has proved to be a powerful feature to support the design of development environments and to extend languages. However, the granularity of structural reflection stops at the method level. This is a problem since without sub-method reflection developers have to duplicate efforts, for example to introduce transparently pluggable type-checkers or fine-grained profilers. In this paper we present Persephone, an efficient implementation of a sub-method meta-object protocol (MOP) based on AST annotations and dual methods (a compiled method and its meta-object) that reconcile AST expressiveness with bytecode execution. We validate the MOP by presenting TreeNurse, a method instrumentation framework and TypePlug, an optional, pluggable type system which is based on Persephone.

MashMaker is a web-based tool that makes it easy for normal users to create mashups from live data on the internet. Users can query, combine, and explore data, using an interface inspired by spreadsheets and web browsers. Like a spreadsheet, MashMaker mixes program and data and allows ad-hoc unstructured editing of programs. Like a web browser, MashMaker allows users to find the information they are interested in by browsing, rather than writing code, and allows users to bookmark interesting things they find, forming new widgets — reusable mashup fragments. MashMaker is also a modern functional programming language with non-side effecting expressions, higher order functions, and lazy evaluation. We argue that a functional language provides an excellent model to allow users to easily create mashups from web data. In order to cope with this unusual domain, MashMaker contains a number of deviations from normal functional programming languages. Data is live, programs are mixed with data, map and fold operations are described using direct manipulation of data, data is structured like a file-system, and it is possible to write a program largely by browsing around, without having to type or decide in advance what one wants to do.

Traditional formal methods and modern agile methods are separated more by limitations of current technology than by fundamental intellectual differences. A mixed interpreter that executes mixed programs, comprising both declarative specification statements and regular imperative statements, might bridge the gap. This paper explores how such an interpreter might be used, showing by example how it might support a variety of development activities.

Side effects are both the essence and bane of imperative programming. The programmer must carefully coordinate actions to manage their side effects upon each other. Such coordination is complex, error-prone, and fragile. Coherent reaction is a new model of change-driven computation that coordinates effects automatically. State changes trigger events called reactions that in turn change other states. A coherent execution order is one in which each reaction executes before any others that are affected by its changes. A coherent order is discovered iteratively by detecting incoherencies as they occur and backtracking their effects. Unlike alternative solutions, much of the power of imperative programming is retained, as is the common sense notion of mutable state. Automatically coordinating actions lets the programmer express what to do, not when to do it. Coherent reactions are embodied in the Coherence language, which is specialized for interactive applications like those common on the desktop and web. The fundamental building block of Coherence is the dynamically typed mutable tree. The fundamental abstraction mechanism is the virtual tree, whose value is lazily computed, and whose behavior is generated by coherent reactions.

The Subtext project seeks to make programming fundamentally easier by altering the nature of programming languages and tools. This paper defines an operational semantics for an essential subset of the Subtext language. It also presents a fresh approach to the problems of mutable state, I/O, and concurrency. Inclusions reify copy & paste edits into persistent relationships that propagate changes from their source into their destination. Inclusions formulate a programming language in which there is no distinction between a program’s representation and its execution. Like spreadsheets, programs are live executions within a persistent runtime, and programming is direct manipulation of these executions via a graphical user interface. There is no need to encode programs into source text. Mutation of state is effected by the computation of hypothetical recursive variants of the state, which can then be lifted into new versions of the state. Transactional concurrency is based upon queued single-threaded execution. Speculative execution of queued hypotheticals provides concurrency as a semantically transparent implementation optimization.

Abstract: Lisp programmers constantly carry out experiments in a read-eval-print loop. The experimental activities convince the Lisp programmers that new or modified pieces of programs work as expected. But the experiments typically do not represent systematic and comprehensive unit testing efforts. Rather, the experiments are quick and dirty one shot validations which do not add lasting value to the software, which is being developed. In this paper we propose a tool that is able to collect, organize, and re-validate test cases, which are entered as expressions in a read-eval-print loop. The process of collecting the expressions and their results imposes only little extra work on the programmer. The use of the tool provides for creation of test repositories, and it is intended to catalyze a much more systematic approach to unit testing in a read-evalprint loop. In the paper we also discuss how to use a test repository for other purposes than testing. As a concrete contribution we show how to use test cases as examples in library interface documentation. It is hypothesized—but not yet validated—that the tool will motivate the Lisp programmer to take the transition from casual testing to systematic testing.

A dynamic language promotes ease of use through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle. Live languages go beyond dynamic languages with more ease of use features. A live language supports live programming that provides programmers with responsive and continuous feedback about how their edits affect program execution. A live language is also based on high-level constructs such as declarative rules so that programmers can write less code. A live language could also provide programmers with responsive semantic feedback to enable time-saving services such as code completion. This paper describes the design of a textual live language that is based on reactive data-flow values known as signals and dynamic inheritance. Our language, Super-Glue, supports live programming with responsive semantic feedback, which we demonstrate with a working prototype.

Abstract. The history of Object-Oriented Programming can be interpreted as a continuing quest to capture the notion of abstraction – to create computational artifacts that represent the essential nature of a situation, and to ignore irrelevant details. Objects are defined by their essential behavior, not by their physical representation as data. The basic Object-Oriented paradigm of organizing programs as active objects and message passing has now been accepted by the mainstream, for which ECOOP can be justifiably proud. Future developments in the field will focus on capturing computational ideas that can't be expressed well simply by functional abstraction. Programming will evolve from textual programming languages to using natural language, graphics, demonstrated actions, and other techniques. 1 The revolution is dead. Long live the revolution! ECOOP has plenty to be proud of in its 20-year history of promoting Object-Oriented Programming. Object-Oriented Programming is a revolution, that, largely, we’ve won. At the start of ECOOP, and its sister conference, OOPSLA, in the eighties, OOP

We introduce a class of program editors that present a program using a rich set of transformations; we call these kinds of editors composable presentation editors. Proper use of these kinds of editors appears to lead to more expressive programs—programs whose structure are aligned with the problem they are trying to solve. By default, the composable presentation editor presents program elements textually as concrete syntax and enables typical editor commands on the program. Metadata on program elements control how the transformations are applied. Customized metadata can re-order, pictorialize, collapse, duplicate, or expand the displayed form of program elements and can additionally alter the available editor commands. We have developed a set of presentation techniques to be used by presentation designers (i.e., the programmers who design how a program is presented in the editor). These techniques relate to well-understood programming language design, editor design, and programming best-practices techniques including scoping, higher order functions, refactoring, prettyprinting, naming conventions, syntax highlighting, and text hovers. We introduce two implementations of composable presentation editors and a number of examples showing how programs can be made more expressive when presentation techniques are properly used. The first implementation is the ETMOP, an open editor, where a metaobject protocol is provided that allows language and editor designers to customize the way program elements are displayed. These customizations are called presentation extensions and the corresponding presentation extension protocol acts in a way similar to the way that syntax macros extend the syntax of a language. The second implementation is Embedded CAL, a closed editor that uses these presentation techniques to embed one language (CAL) inside a host language (Java) through the use of presentation techniques, without changing the syntax or compiler of either language.

Abstract. The biggest challenge facing software developers today is how to gracefully evolve complex software systems in the face of changing requirements. We clearly need software systems to be more dynamic, compositional and model-centric, but instead we continue to build systems that are static, baroque and inflexible. How can we better build change-enabled systems in the future? To answer this question, we propose to look back to one of the most successful systems to support change, namely Smalltalk. We briefly introduce Smalltalk with a few simple examples, and draw some lessons for software evolution. Smalltalk’s simplicity, its reflective design, and its highly dynamic nature all go a long way towards enabling change in Smalltalk applications. We then illustrate how these lessons work in practice by reviewing a number of research projects that support software evolution by exploiting Smalltalk’s design. We conclude by summarizing open issues and challenges for change-enabled systems of the future. 1