Search

The intelligent programming assistant, directly integrated into the programmer’s workflow, has been a long time dream of programmers and researchers alike. Before the advent of Large Language Models (LLMs), this dream came closest to reality with Program Synthesis in the form of Programming-by-Example, and now tools such as GitHub Copilot have brought a version of it using LLMs to consumers. Alongside the technical developments in Program Synthesis and LLMs that made these tools possible, another area of research has focused on the usability of such tools, investigating user interfaces and interaction models that could most effectively employ these techniques to the benefit of programmers.This dissertation explores the overlap between these research areas, focusing on synchronous program synthesis where the user is in-the-loop, specifying synthesis problems and waiting on the result. It includes human-centered contributions to each step the synthesis process, exploring the use of Live Programming to improve specification in Programming-by-Example in SnipPy and LooPy , an algorithmic contribution to bottom-up enumerative synthesis with side effects in SObEq, and exploring interfaces for validation of AI-generated programs for experienced developers in LEAP, and end user programmers in ColDeco.

A programming environment that visualizes a program’s execution can help users better understand their programs. However, building such an environment for programmers at large is difficult, as it is not clear how to effectively visualize large, complex programs. We would like to make progress on this problem by first focusing on a subproblem: creating a better programming experience for learning and teaching programming. To explore this approach, we built Seymour, a prototype live programming environment that visualizes all events in a program’s execution. Seymour features two complementary visualizations—one that shows a detailed view of a method call, and another that depicts the whole execution at a high level. These two visualizations come together to create a compelling user experience that we plan to test and improve with student feedback

This dissertation includes contributions to both live programming and program verification and explores how programming environments can be designed to leverage benefits of both concepts in an integrated way.Programming environments assist users in both writing program code and understanding program behavior. A fast feedback loop can significantly improve this process. In particular, live programming provides continuous feedback for live code updates of running programs. This idea can also be applied to program verification. In general, verifiers statically check programs based on source code annotations such as invariants, pre- and postconditions. However, verification errors are often hard to understand, so programming environment integration is crucial for supporting the development process.The research for this dissertation involved the implementation of esverify, a program verifier for JavaScript, as well as prototype implementations of multiple programming environments. These implementations demonstrate potential benefits and limitations of proposed solutions and enable empirical evaluation with case and user studies. Additionally, the proposed designs were formally defined in order to explain the core idea in a concise way and to prove properties independent of concrete specifics of existing systems and programming languages.The resulting systems represent possible solutions in a vast design space with various contributions. The research on live programming showed that a programming model that separates event handling from output rendering enables not only live code updates but also runtime version control and programming-by-example. For program verification, esverify represents a novel approach for static verification of both higher-order functional programs and dynamically-typed programming idioms. esverify can verify nontrivial algorithms such as MergeSort and a formal proof in the Lean theorem prover shows that its verification rules are sound. Finally, a programming environment based on esverify supports inspection and live edits of verification conditions including step-by-step debugging of automatically generated tests that serve as executable counterexamples. As part of a user study, participants used these features effectively to solve programming tasks and generally found them to be helpful or potentially helpful.

Live programming is a paradigm in which values from program execution are shown to the programmer through continual feedback. Programming by example is a paradigm in which code is synthesized from example values showing a desired behavior. This talk presents some of our recent research that combines these two paradigms in beneficial ways. I will walk through our ideas, explain our contributions, discuss what we learned and finally provide thoughts for the future.

As developers program and debug, they continuously edit and run their code, a behavior known as edit-run cycles. While techniques such as live programming are intended to support this behavior, little is known about the characteristics of edit-run cycles themselves. To bridge this gap, we analyzed 28 hours of programming and debugging work from 11 professional developers which encompassed over three thousand development activities. We mapped activities to edit or run steps, constructing 581 debugging and 207 programming edit-run cycles. We found that edit-run cycles are frequent. Developers edit and run the program, on average, 7 times before fixing a defect and twice before introducing a defect. Developers waited longer before again running the program when programming than debugging, with a mean cycle length of 3 minutes for programming and 1 minute for debugging. Most cycles involved an edit to a single file after which a developer ran the program to observe the impact on the final output. Edit-run cycles which included activities beyond edit and run, such as navigating between files, consulting resources, or interacting with other IDE features, were much longer, with a mean length of 5 minutes, rather than 1.5 minutes. We conclude with a discussion of design recommendations for tools to enable more fluidity in edit-run cycles., VL/HCC 2021

Supplementary descriptions for the design of a live game development environment as described in the paper "Shortening Feedback Loops in a Live Game Development Environment". The descriptions include more details on the approach, more detailed accounts on the development of the game prototypes, and a more in-depth discussion of consequences of the design.

Dalam mempelajari bahasa pemrograman atau framework bahasa pemrograman tertentu yang digunakan untuk pengembangan web, mahasiswa dapat mempelajarinya secara mandiri dengan cara menonton video pembelajaran, membaca dokumentasi, membaca buku mengenai hal tersebut. Namun, cara tersebut lebih cenderung satu arah, dimana, pembelajar tidak dapat mencoba langsung contoh kasus dalam media-media tersebut. Mereka harus membuka editor, membuka browser, menyalakan server lokal, menulis ulang contoh, dan menjalankan program. Perpindahan jendela aplikasi merepotkan pembelajar. Scrimba merupakan sebuah inovasi multimedia pembelajaran di mana pengguna dapat menonton video pembelajaran sekaligus berinteraksi langsung pada kode program, dan menjalankan program saat video dihentikan. Editor program, video pembelajaran, dan browser untuk menguji program ada pada satu layar. Penelitian ini bertujuan untuk mengetahui penerimaan pembelajar terhadap Scrimba, bagaimana interaksi mereka dan bagaimana kepuasan mereka. Metode penelitian yang digunakan adalah metode deskriktif dengan pendekatan survei. Penelitian dilakukan terhadap mahasiswa berprogram studi Informatika yang telah mengeksplorasi sebuah materi pembelajaran yang dirasakan sebagian besar oleh mereka sulit. Dosen merekam tutorial pembelajaran di Scrimba yang dibagikan kepada mahasiswa untuk dipelajari. Hasil penelitian menemukan bahwa Scrimba berkontribusi positif terhadap pemahaman materi pembelajaran dan kepuasan mahasiswa dalam mempelajari materi di Scrimba. Rata-rata hasilnya didominasi pada level cukup baik yakni sebesar 42,55% ke baik dan sangat baik yang jika dijumlahkan sebesar 49,03%. Sehingga, dapat disimpulkan bahwa Scrimba dapat menjadi salah satu alternatif alat pembelajaran untuk mempelajari pengembangan web yang layak digunakan untuk pembelajaran jarak jauh. Bahkan, pendekatan rekaman layar dan audio dan kode editor dalam satu layar seperti di Scrimba dapat menjadi pendekatan untuk pengembangan alat pembelajaran pemrograman secara lebih luas.

Text editing is powerful, but some types of expressions are more naturally represented and manipulated graphically. Examples include expressions that compute colors, music, animations, tabular data, plots, diagrams, and other domain-specific data structures. This paper introduces live literals, or livelits, which allow clients to fill holes of types like these by directly manipulating a user-defined GUI embedded persistently into code. Uniquely, livelits are compositional: a livelit GUI can itself embed spliced expressions, which are typed, lexically scoped, and can in turn embed other livelits. Livelits are also uniquely live: a livelit can provide continuous feedback about the run-time implications of the client’s choices even when splices mention bound variables, because the system continuously gathers closures associated with the hole that the livelit is filling. We integrate livelits into Hazel, a live hole-driven programming environment, and describe case studies that exercise these novel capabilities. We then define a simply typed livelit calculus, which specifies how livelits operate as live graphical macros. The metatheory of macro expansion has been mechanized in Agda.

End-user programmers opportunistically copy-and-paste code snippets from colleagues or the web to accomplish their tasks. Unfortunately, these snippets often don’t work verbatim, so these people—who are non-specialists in the programming language—make guesses and tweak the code to understand and apply it successfully. To support their desired workflow and facilitate tweaking and understanding, we built a prototype tool, TweakIt, that provides users with a familiar live interaction to help them understand, introspect, and reify how different code snippets would transform their data. Through a usability study with 14 data analysts, participants found the tool to be useful to understand the function of otherwise unfamiliar code, to increase their confidence about what the code does, to identify relevant parts of code specific to their task, and to proactively explore and evaluate code. Overall, our participants were enthusiastic about incorporating TweakIt in their own day-to-day work.

The use of physical computing devices as teaching tools presents several challenges for educators and learners. Most introductory programming environments help to learn programming by removing the possibility of syntax errors, usually by using a visual programming language. However, understanding syntax is just one aspect of the learning process. One of the most challenging tasks for students is to build a correct mental model of the underlying machine model and its execution dynamics. Additionally, visual programming languages present issues when transitioning to text-based languages. In this paper we present Physical Bits, a web-based programming environment for educational robotics that attempts to solve these issues by providing a live programming experience using both visual and textual programming languages.

Our community has explored various approaches to improve the programming experience. Although many of them, such as Example-Based Live Programming (ELP), have shown to be effective, they are still not widespread in conventional programming environments. A reason for that is the effort required to provide sophisticated tools that rely on run-time information. To target multiple language ecosystems, it is often necessary to implement the same concepts, but for different languages and runtimes. Two emerging technologies present an opportunity to reduce this effort significantly: the Language Server Protocol (LSP) and language implementation frameworks such as GraalVM's Truffle. In this paper, we show how an ELP system can be built in a language-agnostic way by leveraging these two technologies. Based on our approach, we implemented the Babylonian Programming system, an ELP system that has previously only been implemented for exploratory ecosystems. Our system, on the other hand, brings ELP for all languages supported by the GraalVM to Visual Studio Code (VS Code). Moreover, we outline what a language-agnostic infrastructure needs to provide and how the LSP could be extended to support ELP also independently from programming environments. Further, we demonstrate how our approach enables the use of ELP in the context of polyglot programming. We illustrate the consequences of our approach by discussing its advantages and limitations and by comparing the features of our system to other ELP systems. Moreover, we give an outlook of how tools that rely on run-time information could be built in the future. This in turn might motivate future tool builders and researchers to consider implementing more tools in a language-agnostic way from the start to make them available to a broader audience.

Live programming is a paradigm in which the programmer can visualize the runtime values of the program each time the program changes. The promise of live programming depends on using test cases to run the program and thereby provide these runtime values. In this paper we show that in some situations test cases are insufficient in a fundamental way, in that there are no test inputs that can drive certain incomplete loops to produce useful data, a problem we call the loop-datavoid problem. The problem stems from the fact that useful data inside the loop might only be produced after the loop has been fully written. To solve this problem, we propose a paradigm called Focused Live Programming with Loop Seeds, in which the programmer provides hypothetical values to start a loop iteration, and then the programming environment focuses the live visualization on this hypothetical loop iteration. We introduce the loop-datavoid problem, present our proposed solution, explain it in detail, and then present the results of a user study.

Live programming is a paradigm in which the programming environment continually displays runtime values. Program synthesis is a technique that can generate programs or program snippets from examples. \deltextThis paper presents a new programming paradigm called Synthesis-Aided Live Programming that combines these two prior ideas in a synergistic way. When using Synthesis-Aided Live Programming, programmers can change the runtime values displayed by the live \addtextPrevious works that combine the two have taken a holistic approach to the way examples describe the behavior of functions and programs. This paper presents a new programming paradigm called Small-Step Live Programming by Example that lets the user apply Programming by Example locally. When using Small-Step Live Programming by Example, programmers can change the runtime values displayed by the live visualization to generate local program snippets. % Live programming and program % synthesis work perfectly together because the live programming environment % reifies values, which makes it easy for programmers to provide the examples % needed by the synthesizer. We implemented this new paradigm in a tool called \toolname, and performed a user study on $13$ programmers. Our study finds that Small-Step Live Programming by Example with \toolname helps users solve harder problems faster, and that for certain types of queries, users prefer it to searching the web. Additionally, we identify the \usersynthgap, in which users' mental models of the tool do not match its ability, and needs to be taken into account in the design of future synthesis tools.

With the increased complexity of digital architectures and aggregation of specialized hardware, functional simulation has become a major bottleneck in digital design. During functional and performance verification of a design, engineers make several iterations to determine the impact of code changes into the simulation result. These iterations are time-consuming both because the compilation time of hardware description to binary is slow and because simulation can take several hours until the point of interest is reached. In contrast, live programming environments allow developers to manipulate the system under development as it is being run. They have become increasingly popular as they provide rapid feedback, yet there is no available live environment for hardware development. In this paper, we propose a live programming and simulation environment that targets hardware design. Our approach is language-independent and leverages incremental compilation, hot binary reloading, and checkpointing to provide fast feedback to the user. We take special care to not replicate code for multiple instances of the same module and thus prevent code bloat, for instance, for multi-and many-core architectures. Our framework also is careful in verifying the consistency across checkpoints, to leverage parallel execution and reduce the amount of code that requires compilation. Our results show that this approach can provide simulation feedback in under 2 seconds, even when simulating a 256 RISC-V multicore architecture. As a reference, Verilator did not finish compiling this architecture after 24 hours of runtime.

Computers have become ubiquitous in our life and work, and the way that they are built and used needs to be fundamentally improved. Most of the prior effort has been aimed at improving the programming experience for people with specific technical backgrounds (e.g., programmers, end-users, data scientists). In contrast, throughout this paper, we discuss how to make programming activities more inclusive and collaborative, involving people with diverse technical backgrounds. We rethink the programming environment from both technical and social perspectives. First, we briefly introduce our previous technical effort in which the programming environment is shared between the developers and users of programs, eliminating the distinction between programming and runtime environments and fostering communication between them. Second, we introduce our social effort to support people who are visually impaired in implementing customized smart glasses that read words with a camera and speakers. We design their programming environment to consist of a softwarehardware toolkit and engineers with domain expertise called “evangelists.” Learning from these experiences, we discuss several perspectives on convivial computing. To conclude, we argue that both technical innovations made on user interfaces for programming and understanding on the socio-technical aspect of domain-specific applications are critical for the future of programming environments, and accordingly, convivial computing.

Artificial intelligence (AI) such as deep learning has achieved significant success in a variety of application domains. Several visualization techniques have been proposed for understanding the overall behavior of the neural network defined by deep learning code. However, they show visualization only after the code or network definition is written and it remains complicated and unfriendly for newbies to build deep neural network models on a code editor. In this paper, to help user better understand the behavior of networks, we augment a code editor with instant and editable visualization of network model, inspired by live programming which provides continuous feedback to the programmer., OASIcs, Vol. 76, 10th Workshop on Evaluation and Usability of Programming Languages and Tools (PLATEAU 2019), pages 7:1-7:5

Live programming is a style of development characterized by incremental change and immediate feedback. Instead of long edit-compile cycles, developers modify a running program by changing its source code, receiving immediate feedback as it instantly adapts in response. In this paper, we propose an approach to bridge the gap between running programs and textual domain-specific languages (DSLs). The first step of our approach consists of applying a novel model differencing algorithm, TMDIFF, to the textual DSL code. By leveraging ordinary text differencing and origin tracking, TMDIFF produces deltas defined in terms of the metamodel of a language. In the second step of our approach, the model deltas are applied at run time to update a running system, without having to restart it. Since the model deltas are derived from the static source code of the program, they are unaware of any run-time state maintained during model execution. We therefore propose a generic, dynamic patch architecture, RMPATCH, which can be customized to cater for domain-specific state migration. We illustrate RMPATCH in a case study of a live programming environment for a simple DSL implemented in RASCAL for simultaneously defining and executing state machines.

As physical computing devices proliferate, researchers and educators push to make them more engaging to learners. One approach is to make the act of programming them more interactive and responsive via live programming so that program edits are immediately reflected in the behavior of the physical device. To understand the impact of live programming on interactions with physical computing devices, we conducted a comparative study where children ages 11-15 programmed a BBC micro:bit device using either the MicroBlocks live programming environment or MakeCode, the micro:bit default environment. Results show that MicroBlocks users spent more time interacting directly with the physical device while showing different patterns of interaction compared to MakeCode users. We also found variations in the differences between environments related to activity structures. This paper contributes to the growing body of literature on how the design of interfaces---like programming environments---for physical computing devices shapes emerging interaction patterns.

Live programming is a novel approach for programming practice. Programmers are given real-time feedback when writing code, traditionally via a graphical user interface. Despite live programming's practical values, such as providing an easier overview of code and better understanding of its structure, it is not yet widely used. In this work, we extend live programming to general purpose code editors, which allows for live programming to be used by programmers, and provides new interfaces for understanding and changing the functionality of code. To achieve this we extended a fully-featured IDE with the ability to show input/output examples of code execution, as the programmer is writing code. Furthermore, we integrate programming by example (PBE) synthesis into our tool by allowing the user to change the shown output, and have the code update automatically. Our goal is to use live programming to give novice programmers a new way to interact and understand programming, as well as being a useful development tool for more advanced programmers.

A key argument in favor of live programming languages and environments is that a better programming experience is achieved through maximizing feedback to the programmer. Intuitively, this is a compelling argument, but looking at validations of live programming languages and environments, the results are not encouraging at all. This essay concerns the question whether it is possible to validate that live programming is faster, or more correct, or that programmers have a better development experience. I provide a critical review of validations of live programming and talk about my own experience with such a user study. The goal of this text is to contrast the intuition with the scientific validation, such that we, as a community, can ask ourselves the question of whether we can validate the arguments in favor of live programming, and if so, how.

Live Programming is an idea pioneered by programming environments from the earliest days of computing, such as those for Lisp and Smalltalk. One thing they had in common is liveness: an always accessible evaluation and nearly instantaneous feedback, usually focused on coding activities. In this paper, we argue for Live Software Development (LiveSD), bringing liveness to software development activities beyond coding, to make software easier to visualize, simpler to understand, and faster to evolve. Multiple challenges may vary with the activity and application domain. Research on this topic needs to consider the more important liveness gaps in software development, which representations and abstractions better support developers, and which tools are needed to support it.

In an increasingly connected world where all manner of devices can communicate over the Internet, conventional methods for developing GUIs (Graphical User Interfaces) are insufficient. For systems of such devices, it must be possible to develop the system itself independently from its GUI(s). In this paper, we present an approach for developing GUIs towards already deployed, or "live", service-based distributed systems without the need to write any program code ("glue code"). The results include an implementation for the middleware framework PalCom and the mobile platform Android, with development tools; they have been tested in several research projects and have been used for developing commercial products.

Based on context-oriented programming (COP), we implemented source code instrumentation for example-based live programming in a modular way. These tools provide programmers with feedback on the dynamic program behavior by showing traced values of example invocations of a program. For that, we have to trace intermediate, expression-level runtime states during the execution of an example. As the instrumentation is only intended to improve tool support, the default behavior of the system must not be altered. In this paper, we demonstrate how context-oriented programming can be used to keep the execution of examples separate from the default behavior even in the presence of expression-level behavior variations. We illustrate our approach by implementing Babylonian Programming using ContextS2 in Squeak/Smalltalk. Based on the implementation, we compare our COP-based Smalltalk implementation to the module-rewriting-based implementation for JavaScript.

Updating applications during their execution is used both in production to minimize application downtime and in integrated development environments to provide live programming support. Nevertheless, these two scenarios present different challenges making Dynamic Software Update (DSU) solutions to be specifically designed for only one of these use cases. For example, DSUs for live programming typically do not implement safe point detection or instance migration, while production DSUs require manual generation of patches and lack IDE integration. These solutions also have a limited ability to update themselves or the language core libraries and some of them present execution penalties outside the update window.In this PhD, we propose a unified DSU named gDSU for both live programming and production environments. gDSU provides safe update point detection using call stack manipulation and a reusable instance migration mechanism to minimize manual intervention in patch generation. It also supports updating the core language libraries as well as the update mechanism itself thanks to its incremental copy of the modified objects and its atomic commit operation.gDSU does not affect the global performance of the application and it presents only a run-time penalty during the update window. For example, gDSU is able to apply an update impacting 100,000 instances in 1 second making the application not responsive for only 250 milliseconds. The rest of the time the application runs normally while gDSU is looking for a safe update point during which modified elements will be copied.We also present extensions of gDSU to support transactional live programming and atomic automatic refactorings which increase the usability of live programming environments., Mettre à jour des applications durant leur exécution est utilisé aussi bien en production pour réduire les temps d’arrêt des applications que dans des environnements de développement interactifs (IDE pour live program- ming). Toutefois, ces deux scénarios présentent des défis différents qui font que les solutions de mise à jour dy- namique (DSU pour Dynamic Software Updating) existantes sont souvent spécifiques à l’un des deux. Par exemple, les DSUs pour la programmation interactive ne supportent généralement pas la détection automatique de points sûrs de mise à jour ni la migration d’instances, alors que les DSUs pour la production nécessitent une génération manuelle de l’ensemble des modifications et manquent d’intégration avec l’IDE. Les solutions existantes ont également une capacité limitée à se mettre à jour elles-mêmes ou à mettre à jour les bibliothèques de base du langage; et certaines d’entre elles introduisent même une dégradation des performances d’exécution en dehors du processus de mise à jour.Dans cette thèse, nous proposons un DSU (nommé gDSU) unifié qui fonctionne à la fois pour la programmation interactive et les environnements de production. gDSU permet la détection automatique des points sûrs de mise à jour en analysant et manipulant la pile d’exécution, et offre un mécanisme réutilisable de migration d’instances afin de minimiser les interventions manuelles lors de l’application d’une migration. gDSU supporte également la mise à jour des bibliothèques du noyau du langage et du mécanisme de mise à jour lui-même. Ceci est réalisé par une copie incrémentale des objets à modifier et une application atomique de ces modifications.gDSU n’affecte pas les performances globales de l’application et ne présente qu’une pénalité d’exécution lors processus de mise à jour. Par exemple, gDSU est capable d’appliquer une mise à jour sur 100 000 instances en 1 seconde. Durant cette seconde, l’application ne répond pas pendant 250 milli-secondes seulement. Le reste du temps, l’application s’exécute normalement pendant que gDSU recherche un point sûr de mise à jour qui consiste alors uniquement à copier les éléments modifiés.Nous présentons également deux extensions de gDSU permettant un meilleur support du développement interac- tif dans les IDEs : la programmation interactive transactionnelle et l’application atomique de reusinages (refactorings).

As TV viewing on mobile devices increases, Korean broadcasters provide video clips that are made by re-editing the length or format of existing broadcast content. Traditional broadcasters and cable networks provide the edited video clips of their full live programs for free. The number of video clips for each live program is different, but generally 5 to 10 video clips for each live program are provided via online or mobile. understand the behavior of video clip consumers. This study is to understand the behavior of video clip consumers. We tried to examine how video clip consumers use video clip services according to their preferences and viewing habits. This study also aims to investigate the reason why Korean people watch short clips of television content. This study investigated the relationship between video clip use motives and actual usage of video clips. To analyze additional promotional effect of video clips, this study explore what motives are related to the intention to watch the live programs and to purchase VOD.

International audience; Many frameworks exist for programmers to develop and deploy Big Data applications such as Hadoop Map/Reduce and Apache Spark. However, very little debugging support is currently provided in those frameworks. When an error occurs, developers are lost in trying to understand what has happened from the information provided in log files. Recently, new solutions allow developers to record & replay the application execution, but replaying is not always affordable when hours of computation need to be re-executed. In this paper, we present an online approach that allows developers to debug Big Data applications in isolation by moving the debugging session to an external process when a halting point is reached. We introduce IDRA MR , our prototype implementation in Pharo. IDRA MR centralizes the debugging of parallel applications by introducing novel debugging concepts, such as composite debugging events, and the ability to dynamically update both the code of the debugged application and the same configuration of the running framework. We validate our approach by debugging both application and configuration failures for two driving scenarios. The scenarios are implemented and executed using Port, our Map/Reduce framework for Pharo, also introduced in this paper.

A live programming environment allows programmers to edit programs while they are running. This means that successive "edit steps" must not allow a programmer to bring the program in a form that does not make any sense to the underlying language processor (i.e., parser, compiler,...). Many live programming environments therefore rely on disciplined edit steps that are based on language elements such as objects, classes, and methods. Textual modifications to these elements are not seen as edit steps until some "accept" button is hit. Unfortunately, no such elements exist in current reactive languages. We present a new reactive language, called Haai, that is based on first-class higher-order reactors. Linguistically, Haai programs correspond to reactors or compositions of reactors. At run-time, reactors produce an infinite stream of values just like signals and behaviours in existing languages. Haai's live programming environment relies on textual modifications of entire reactors as its basic edit steps. Changing a reactor automatically updates all occurrences of that reactor in the reactive program, while it is running.

We present Nezt -- a prototype of a live programming environment inspired by spreadsheets, but with a more expressive computational model. In contrast to traditional spreadsheets, cells can contain other cells in a hierarchical fashion, and one can define custom functions and use them in formulas. Our goal is to share some of the accessibility, immediacy and ease of use of spreadsheets, while achieving broad applicability, especially in the areas of application prototyping and scientific computing. The project is motivated by our own needs, but we hope it could be useful to many different types of users including advanced end-users like scientists who program as part of their work. Design influences include Excel, Lisp, JetBrains MPS and Boxer. The ultimate goal is a versatile live programming environment without the accidental complexities of mainstream professional programming.

PalCom is a middleware toolkit for pervasive computing and internet-of-things. We discuss how PalCom supports exploration and live programming through three phases: exploring services, assembling them into applications, and exposing them as new services. We give an example of this workflow through the construction of a simple photo booth application.