Living it up with a Live Programming Language Sean McDirmid Ecole´ Polytechnique Fed´ erale´ de Lausanne (EPFL) 1015 Lausanne, Switzerland sean.mcdirmid@epfl.ch Abstract eliminating verbose type annotations. Dynamic languages A dynamic language promotes ease of use through flexible also emphasize high-level programming models, often based typing, a focus on high-level programming, and by stream- on higher-order functions or objects, that reduce the amount lining the edit-compile-debug cycle. Live languages go be- of code needed to express a program. Together, flexible typ- yond dynamic languages with more ease of use features. A ing and high-level programming models support component live language supports live programming that provides pro- programming so that programmers can create feature-rich grammers with responsive and continuous feedback about programs with little code by reusing existing components. how their edits affect program execution. A live language Finally, dynamic language environments streamline the edit- is also based on high-level constructs such as declarative compile-debug cycle by either eliminating or hiding compi- rules so that programmers can write less code. A live lan- lation and by allowing code to be changed while a program guage could also provide programmers with responsive se- is running. For example, many Lisp [25], Smalltalk [12], and mantic feedback to enable time-saving services such as code Erlang [1] environments support hot swapping where a pro- completion. This paper describes the design of a textual live gram’s code can be updated without restarting. language that is based on reactive data-flow values known Can we design languages that are easier to use than ex- as signals and dynamic inheritance. Our language, Super- isting dynamic languages? For inspiration, look at visual Glue, supports live programming with responsive semantic languages such as Fabrik [15], LabVIEW [21], and spread- feedback, which we demonstrate with a working prototype. sheet languages such as Excel and Forms/3 [3], which are designed to be used by casual programmers, novices, and Categories and Subject Descriptors D.2.6 [Programming even end users. Visual languages are based on simple, of- Environments]: Interactive Environments—live program- ten declarative, programming models that heavily empha- ming; D.3.2 [Programming Languages]: Data-flow, Very size component reuse. For example, Apple’s Quartz Com- High-level, and Object-oriented Languages; D.3.3 [Lan- poser [17] supports the assembly of animation components guage Constructs and Features]: Inheritance—dynamic. through reactive data-flow connections that encapsulate General Terms Human Factors and Languages change-propagation details. The simple programming mod- els of visual languages also enable live programming, which 1. Introduction provides programmers with immediate and continuous feed- back about how their edits affect program execution. For Dynamic programming languages support rapid develop- example, editing a connection graph in Quartz Composer ment by reducing verbosity in both source code and the de- immediately changes the composed animation. Compared to velopment process. Although labeled as “dynamic” because live programming, the hot swapping supported by dynamic they often rely on dynamic typing, dynamic languages are languages is mushy: the effect of edited code on program best characterized by their emphasis of flexibility, concise- behavior is not apparent until the code is re-executed. For ness, and ease of development over performance and gen- example, editing the Smalltalk statement “w fill: red” to erality. Dynamic typing promotes flexibility by enforcing “w fill: blue” will not immediately re-color blue all wid- fewer restrictions on type compatibility and conciseness by gets that have been bound to w. In spite of their benefits, visual languages do not replace textual dynamic languages. For one thing, text can be writ- Permission to make digital or hard copies of all or part of this work for personal or ten more quickly [23]. More significantly, visual languages classroom use is granted without fee provided that copies are not made or distributed must deal with a scaling-up problem [4]: the ability to build for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute large programs is hindered by concrete visual notation that to lists, requires prior specific permission and/or a fee. does not easily support abstraction. Modern visual languages OOPSLA’07, October 21–25, 2007, Montreal,´ Quebec,´ Canada. solve the scaling up problem in a variety of ways; e.g., Copyright c 2007 ACM 978-1-59593-786-5/07/0010. $5.00 623 Forms/3 [3] allow for name-based cell referencing and data programming remains responsive, SuperGlue supports error abstraction through generic forms. Still, text’s natural sup- recovery where syntax, semantic, and execution errors are port for naming makes it more suitable for many abstraction- noted in the background while execution continues. The live heavy programming tasks. Also, the simple programming programming experience that is shown as a frame-expanded models that enable live programming in visual languages can movie1 in Figure 1 is narrated as follows: also be applied to textual languages. A live language is then a textual or visual language that supports live programming (a) The programmer types “port pacMan . Figure” to de- through a simple programming model. fine a pacMan signal that extends the game’s Figure class Support for textual naming in a live language is problem- so pacMan is drawn on the game’s canvas. Because a atic: how are programmers provided with responsive seman- shape for pacMan has not been specified, it is drawn by tic feedback about what names are valid? Semantic feedback default as a rectangle. speeds up the programming process by detecting typos early (b) The programmer types the extension “pacMan . Pie,” on and enabling services such as code completion, which al- which causes pacMan to extend the Pie class and be lows programmers to browse available resources. Program- drawn as a circle. The shape of pacMan is updated on mers are often deprived of responsive semantic feedback in screen as soon as the programmer types the “e” in Pie. dynamically-typed languages because names are difficult to (c) The programmer types the connection “pacMan.fill = resolve before run-time. Static typing that typically enables yellow,” causing this circle to be immediately colored semantic feedback is too verbose and inflexible to be used yellow. Through type inference, code completion can in a live language. Implicit typing would work better in a complete typing for .fill in pacMan. live language where inference provides responsive semantic feedback without type annotations. (d) The programmer types “pacMan.extent = 330.” As the This paper explores the design of a textual live language programmer types each character in “330,” pacMan’s ap- that reuses ideas from dynamic and visual languages along pears respectively as a 357, 327, and finally a 30 de- with a few new ideas. The language, SuperGlue, is based gree slice. The programmer than finishes this line with on a simple reactive data-flow programming model that is “+ (time % 30),” which causes pacMan’s mouth to close suited to building interactive programs out of existing com- continuously in a 30 degree motion. ponents. Components in SuperGlue are connected together The rest of this paper is organized as follows. Section 2 through signals into a data-flow graph. Being reactive, the lists live language design problems and how these problems values that flow across signal connections can change over are solved in SuperGlue. Section 3 describes how SuperGlue time, which eases the expression of interactive programs. supports live programming. Section 4 describes preliminary For scaling purposes, signals extend classes through dy- experience on SuperGlue’s use in developing a simple game. namic inheritance, where what classes a signal extends can Section 5 presents related work and Section 6 concludes. change at run time. Signals and dynamic inheritance seam- lessly support live programming by masquerading edits as 2. Language Design programmatic changes in the program’s mutable execution state. Unlike Self [29] and like Cecil [6], dynamic inheri- SuperGlue is based on the data-flow programming model tance in SuperGlue is based on declarative predicates [7], that was originally introduced by Karp and Miller [16] to which is very compatible with a reactive data-flow model. deal with concurrency through a graph program represen- Because class extensions are declarative, type inference can tation. Even without considering concurrency, the data-flow provide programmers with responsive semantic feedback. model is appealing to live languages because all computa- Dependent typing improves type inference so that type an- tional dependencies are encoded explicitly. The data-flow notations are unnecessary. model by itself does not scale: non-trivial programs involve a Previous work [20] introduces SuperGlue’s support for large or unbounded number of data-flow connections that are object-oriented signals, and shows how this support eases tedious or impossible to express individually. For this rea- the construction of interactive programs. This paper expands son, SuperGlue augments its data-flow model with object- on this work by augmenting SuperGlue with dynamic inher- oriented constructs. As a brief overview, SuperGlue consists itance, which significantly simplifies the language, and live of the following constructs: programming. Figure 1 shows how live programming occurs – Signals, which are data-flow values that facilitate inter- in a working Eclipse-based prototype. In this paper, we use component communication. Signals are objects that ex- a PacMan-like game as a running example. A program is tend classes, are connected to other signals, and contain edited freely as text in the upper half of the programming signals defined in their extended classes. Signals are de- environment while the execution is shown in the lower half.