# It's Alive! What a Live Object Environment Changes in Software Engineering Practice

Julián Grigera, Steven Costiou, Juan Cruz Gardey, Stéphane Ducasse

## ► To cite this version:

Julián Grigera, Steven Costiou, Juan Cruz Gardey, Stéphane Ducasse. It's Alive! What a Live Object Environment Changes in Software Engineering Practice. IDE 2026 - 3rd International Workshop on Integrated Development Environments, Apr 2026, Rio de Janeiro, Brazil. hal-05407907

HAL Id: hal-05407907

https://inria.hal.science/hal-05407907v1

Submitted on 9 Dec 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# It's Alive! What a Live Object Environment Changes in Software Engineering Practice

Julián Grigera

juliang@lifia.info.unlp.edu.ar

LIFIA, Fac. de Informática, Univ. Nac. de La Plata

La Plata, Argentina

CONICET

Buenos Aires, Argentina

Steven Costiou

steven costiou@inria.fr

Inria

Lille, France

Juan Cruz Gardey

jcgardey@lifia.info.unlp.edu.ar

LIFIA, Fac. de Informática, Univ. Nac. de La Plata

La Plata, Argentina

Stéphane Ducasse

stephane.ducasse@inria.fr

Inria

Lille, France

<figure><img src="image_2.png" /><figcaption>Figure 1: Pharo: a powerful tool boosted IDE for live programming and XTDD</figcaption></figure>

## Abstract

Tools shape our mind. This is why it is important to have extensible and flexible tools that developers can adapt to their needs. In addition, coding in the abstract (thinking about what objects will look like) adds abstraction to the wrong level. In Smalltalk environments like Pharo, developers interact closely with their objects, gaining immediate feedback - not guessing how these objects will look like but just talking to them. In this article we present some powerful tools developers use in Pharo: Inspector custom view - to define specific views that support objects' descriptions and navigation, Microcommits - any change is reachable and revertible without the need to commit and pull, Xtreme TDD - developers write tests that fail and code in the debugger in one single flow,

On the Fly Rewriting Deprecations - when developers migrate to libraries whose API changes, they run their tests and the system rewrites adequate call sites to call new version of the API, Object-Centric Breakpoints - when a problem cannot be efficiently solved with a dummy trace, developers can use break points that will only halt for a given instance. By showcasing these features that evolved alongside Smalltalk, we invite reflection on how other IDEs could re-think some of their features and improve developers workflows.

## CCS Concepts

* Software and its engineering → Software testing and debugging; Integrated and visual development environments; Object oriented development.

## Keywords

Pharo, Xtreme TDD, Live programming, Productivity boost, microcommits, on the fly rewriting deprecations

## ACM Reference Format:

Julián Grigera, Steven Costiou, Juan Cruz Gardey, and Stéphane Ducasse. 2026. It's Alive! What a Live Object Environment Changes in Software Engineering Practice. In *Proceedings of (IDE'26 - an ICSE workshop)*. ACM, New York, NY, USA, 4 pages. https://doi.org/XXXXXXX.XXXXXXX

<footnote>Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.</footnote>

<footnote>IDE'26 - an ICSE workshop, Rio de Janeiro, Brazil</footnote>

<footnote>© 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM.</footnote>

<footnote>https://doi.org/XXXXXXX.XXXXXXX</footnote>
# 1 Introduction

Most modern IDEs did not redefine how we build software — they inherited it. They arrived after the languages they support, and simply wrapped the existing compile-run-debug pipeline that came from the command-line era. As a result, the coding process is still largely based on this pipeline. This involves working around files (which is what compilers expect), launching a separate process to run a program, or debugging in an external mode rather than part of execution. Most tools aimed at improving this process are bolt-ons that observe the runtime from the outside. Even though today's IDEs have come a long way, they still promote a linear workflow of edit > build > run > debug, shaping the software engineering process into discrete phases with little continuity of state.

Smalltalk environments — and Pharo in particular — came from a different place [1, 5]. They were co-designed with the language as one live system: the IDE itself is the running program. Code exists as objects in memory rather than text in files, debugging happens inside the execution context, and developers can change methods and immediately resume execution. Tools such as browsers and inspectors share the same object space as the application, blurring the line between “editing” “running” and “analyzing”. As a result, development becomes continuous, exploratory, and conversational rather than linear.

The point is not simply that Pharo has unique features, but that it embodies a fundamentally different mental model of software creation [6-8]. By contrasting these two lineages — the file-based, phase-driven tradition of mainstream IDEs and the live, reflective architecture of Pharo [11] — we can ask how IDE design shapes software engineering practice, and what insights from Pharo might inform the next generation of development environments.

The following sections illustrate 3 scenarios, each highlighting a specific feature of Pharo as an IDE, which could be helpful in reflecting on how traditional IDEs could support a different development process inspired in live environments. To ground these ideas, we use a simple logistics system as a running example. It manages packages, depots, trucks, and delivery routes, and we show how a developer evolves this system inside Pharo's live environment.

# 2 Scenario: Debugger-Driven Development

In Pharo, the debugger is not just for inspecting errors after the fact — it is a fundamental development interface. Users can write or modify methods directly in the debugger, and then resume execution without restarting the system. This enables *Debugger-Driven Development DDD* in a way that mainstream IDEs only partially support. *Debugger-Driven Development* is part of Xtreme TDD (where developers write failing tests and they code in the debugger).

The design of the Pharo debugger focuses on maintaining a streamlined debugging workflow that helps developers concentrate on a single tool for exploring runtime values and behavior.

To illustrate the dynamic nature of Pharo's debugger, we will describe a scenario in which a developer codes a new feature by means of *DDD*. While working on the logistics system, the developer needs to add a new feature: packages located within a depot's service area should be automatically scheduled for delivery. This extension is implemented using *DDD*, with the debugger driving the development process.

*Building from the debugger.* The process begins with writing a unit test before any implementation exists. For example, the developer specifies that a package located within a depot's service area should appear in today's delivery plan by calling something like `RoutePlan schedulePackage: aPackage for: aDate`. The developer executes the test that fails, as expected because the method `RoutePlan>>schedulePackage:for:` does not exist. The debugger opens and prompts the developer to create that missing method in the `RoutePlan` class (Figure 2).

<figure><img src="image_3.png" /><figcaption>**Figure 2: The debugger proposes to create unknown methods.**</figcaption></figure>

The developer uses the debugger to automatically create the missing method. The debugger creates this method and inserts a call to that method in the running execution, showing a new stack frame on that method (Figure 3). Instead of returning to a code editor, the developer implements the method inside the debugger itself, then resumes the paused execution and the test now passes—all within a single live debugging session.

<figure><img src="image_4.png" /><figcaption>**Figure 3: The developer implements the missing method in the debugger and resumes the execution.**</figcaption></figure>

*Generating code with live values.* Let us imagine that the developer continued their development, and are now building new tests. They wrote a method `RoutePlan>>defaultSchedulePlan` and they want to write first basic tests. They would like to write simple tests such as `self assert: RoutePlan new defaultSchedulePlan equals: <something>` but they have yet to determine that `<something>`. They have to either manually check in the source code or to execute an incomplete test with a breakpoint to observe the live value. Instead, the Pharo debugger lets developers write test code such as `self try: RoutePlan new defaultSchedulePlan`. Upon execution, that test opens a debugger
that transform the *try assertion* to a real assertion using run-time values, e.g., `self assert: RoutePlan new defaultSchedulePlan equals: 'success'`.

*Extending the debugger with domain-specific tools.* Now, the development of the logistic system has progressed so that there are multiple scheduling strategies for delivery. The developer wants to explore the execution of delivering strategies by using step-by-step execution in the `schedulePackage:for:` method. However, since there are now multiple scheduling strategies, it exists many methods with the same signature in the system. Therefore, it is hard for the developer to predict which implementation will be called, and it is impractical to set breakpoints in every one of them. This scenario can be approached using *moldable debugging* methods [2], such as extending the debugger with domain-specific tools. The Pharo debugger exposes the *Sindarin* debugging API [4] that developers can use to adapt the debugger to debug their problems. For example, in Figure 4 we see an open debugger with a focus on the scripting pane. In there, we wrote a script that automatically steps the execution until a method with the `schedulePackage:for:` is executed. The script can be executed directly or automatically integrated as a new stepping command in the general debugger toolbar. In effect, we have created a custom stepping operator that advances execution until it reaches our scheduling method, then halts to return control to the developer.

<figure><img src="image_5.png" /><figcaption>**Figure 4: Creation and integration of a new stepping tool.**</figcaption></figure>

## 3 Scenario: Extending the IDE in action

In the previous scenario, the developer implemented delivery scheduling logic. As the system grows, understanding geographic data becomes essential: depots have service areas, packages are associated with locations, and routing decisions depend on boundaries and regions. Working only with raw objects or XML structures quickly becomes cumbersome. In Pharo, however, developers are not limited to textual or tabular representations of data—they can extend the environment itself to better match their domain.

In Pharo, the go-to tool for browsing any object is the inspector. By default, an inspector will show the contents of the object's instance variables, but this behavior can be easily customized to show more useful information in different ways. Objects can define their own custom views (tables, graphs, UI previews, domain-specific widgets), and these tools run in the same object space as the application. This makes analysis and understanding a live, interactive activity instead of a static or external phase.

To illustrate this, imagine that the developer loads an SVG file representing a world map in order to define delivery regions. After

<figure><img src="image_6.png" /><figcaption>**Figure 5: Navigating the tree structure of a SVG world map file.**</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>**Figure 6: Inspecting a list of country objects and seeing their visual aspects.**</figcaption></figure>

parsing the SVG with an `XMLDOMParser`, they may want to explore the internal structure of the document to locate countries or shapes. This can be achieved by creating the document and opening it directly in an inspector:

```
(XMLDOMParser parse: 'world.svg' asFileReference readStream
  contents) document inspect
```

Developers can then freely navigate the tree structure, as shown in Figure 5.

After some simple processing, the developer produces a list of domain objects, each representing a country with its associated SVG path. However, the default visualization is not very informative, since most objects present themselves only as instances of their class (e.g., an `EarthMapCountry`). To improve readability, the first simple step is to redefine `printOn:` so that each object shows its country name throughout the IDE (e.g., an `EarthMapCountry` (France)).

While this improves identification, a far more powerful option is to extend the inspector itself to present a domain-specific view. Listing 3 shows how to add a custom inspector tab that renders the actual shape of the country. With this extension, developers can visually inspect each country directly inside the environment, as shown in Figure 6.

```
EarthMapCountry >> inspectorShape: aBuilder
  <inspectorPresentationOrder: 0 title: 'Shape'
```

```
| canvas |
canvas := RSCanvas new.
canvas add: self asRSShape.
canvas @ RSCanvasController.
^ SpRoassalInspectorPresenter new
canvas: canvas;
yourself
```

This shows how developers can not only inspect data, but adapt and extend the IDE to the domain at hand. In this case, a geographic
visualization becomes a first-class development tool, supporting
understanding and decision-making in the live system.

4 Scenario: Evolution

Refactoring in Pharo is not limited to renaming: it supports trans-
formations and refactorings [9]. But Pharo offers more. Because
the environment is live and reflective, developers can deprecate a
method, automatically track all usages across the running system,
and apply context-sensitive rewrite rules to transform or migrate
call sites incrementally. This enables safe evolution over time, which
is much harder to achieve in traditional file-based IDEs.

To continue with the scenario, imagine that the delivery feature
has been in use for a while. The developer then realizes that the
method schedulePackage:for: is poorly named and does not clearly
express its intent. Before changing it, they want to understand
how widely it is used and how invasive the update might be. To
assess the impact, the developer uses Pharo's reflective naviga-
tion and visualization tools (e.g., senders/implementors browsers
or Inspector-based views) to see where and how the method is
referenced across the system. In addition, since the system records
every compilation action, the developer can roll back to previous
micro-commits and instantly verify the effect of the change on the
examples and tests.

Finally, rather than blindly renaming all occurrences of a method,
the developer can mark the method as deprecated with automated
rewriting behavior. And when the code is executed (for example
running the tests), the environment then automatically rewrites
each executed call site [3].

5 Discussion

Although Pharo's live object model enables these scenarios, many
of the underlying ideas could inspire new directions in mainstream
IDEs. These environments are still organized around discrete phases
 edit, build, run, debug) but the technical distance between them
and live environments could be bridged. Modern IDEs already offer
partial mechanisms that could evolve toward similar practices: hot-
reload in the JVM, inline test execution in VS Code, and stateful
notebooks in PyCharm Fleet all point to a trend toward continuity
between coding and execution.

Xtreme TDD and Debugger-driven development, for instance,
could become more integral if debuggers supported in-context
code creation rather than post-hoc inspection. Instead of opening
a separate editor, a user could define or refine a function directly
in a paused frame and resume execution seamlessly. Similarly,
domain-specific inspectors could be realized through existing plu-
gin architectures. PyCharm already provides structured views (e.g.,
database table viewer or JSON tree explorer), but these are tied
to file formats rather than live domain objects. Opening the plu-
gin API to let developers craft custom, object-aware visualizations
could enrich environments with a moldable inspection model.

Even refactoring and evolution mechanisms can benefit from
a live perspective [10]. Tools like Intelligence's structural search and
replace or VS Code's semantic refactoring already reason about
syntax trees; extending them to operate on live execution contexts,
with awareness of dynamic call sites, would blur the boundary be-
tween static code and running system. These examples suggest that

live-environment ideas do not depend on reflection or image-based
systems—they can emerge gradually within file-based ecosystems.

Adopting such features would not merely enrich developer ex-
perience but could reshape the underlying workflow. Live, object-
centric feedback loops foster experimentation, faster validation,
and a more conversational relationship with the program under
construction. Using Pharo as inspiration thus highlights an op-
portunity: to rethink how mainstream IDEs might close the gap
between editing and running, turning development from a staged
pipeline into an ongoing dialogue with the system itself.

6 Conclusions

Traditional IDEs have evolved greatly since their origins, and helped
shape and speed up the development process. Despite this progress,
the underlying metaphor has not changed: development is still
framed as a sequence of file manipulations rather than a dialogue
with a live system. In this paper, we presented specific features of
Pharo, a live coding environment, not just for advertising it, but
inviting reflection on how an IDE with a different and in some ways
unique history could help re-thinking the usual toolset and even
 workflow. Simply stepping outside the inherited model of file-based
editing could make room for features that make development more
fluid, exploratory, and responsive to the system as it runs.

Acknowledgments

We thank the Pharo consortium and the community for all their
contributions to Pharo.

References

[1] A. P. Black, S. Ducasse, O. Nierstrasz, D. Pollet, D. Cassou, and M. Denker. *Pharo by Example*. Lulu - Square Bracket Associates, Kehrsatz, Switzerland, 2009.

[2] A. Chiş, T. Girba, and O. Nierstrasz. The Moldable Debugger: A framework for developing domain-specific debuggers. In *Software Language Engineering*, pages 102–121. Springer, 2014.

[3] S. Ducasse, G. Polito, O. Zaitsev, M. Denker, and P. Tesone. Deprewriter: On the fly rewriting method deprecations. *Journal of Object Technologies (JOT)*, 21(1), 2022.

[4] T. Dupriez, G. Polito, S. Costiou, V. Aranega, and S. Ducasse. Sindarin: A versatile scripting api for the pharo debugger. In *International Symposium on Dynamic Languages (DLS’19)*, pages 67–79. ACM, 2019.

[5] A. Goldberg. *Smalltalk 80: the Interactive Programming Environment*. Addison Wesley, Reading, Mass., 1984.

[6] J. Kubelka, A. Bergel, A. Chiş, T. Girba, S. Reichhart, R. Robbes, and A. Syrel. On understanding how developers use the Spotter search tool. In *Proceedings of 3rd IEEE Working Conference on Software Visualization - New Ideas and Emerging Results, VISSOFT-NIER’15*, pages 145–149. IEEE, Sept. 2015.

[7] J. Kubelka, R. Robbes, and A. Bergel. The road to live programming: Insights from the practice. In *Proceedings of the 40th International Conference on Software Engineering, ICSE’18*, pages 1090–1101, New York, NY, USA, 2018. ACM.

[8] J. Kubelka, R. Robbes, and A. Bergel. Live programming and software evolu-
tion: Questions during a programming change task. In *2019 IEEE/ACM 27th
International Conference on Program Comprehension (ICPC)*, pages 30–41, 2019.

[9] B. Sarenac, N. Anquetil, S. Ducasse, and P. Tesone. A new architecture reconciling refactorings and transformations. *Journal of Computer Languages*, page 101273, 2024.

[10] P. Tesone, G. Polito, L. Fabresse, N. Bouraqadi, and S. Ducasse. Preserving instance state during refactorings in live environments. *Future Generation Computer Systems*, 110:1–17, 2020.

[11] I. Thomas, V. Aranega, S. Ducasse, G. Polito, and P. Tesone. A vm-agnostic and backwards compatible protected modifier for dynamically-typed languages. *The Art, Science, and Engineering of Programming*, 8, 2024.

Received 27 October 2025; revised 12 December 2009; accepted 5 June 2009