This initial workshop of the Substrates community was held on June 3rd, 2025, hosted at the ‹Programming› 2025 Conference at Prague, Czechia.
The Call for Contributions solicited a selection of vision statements from the invited participants, which were then circulated for critical response. The statements and their responses are collected here.
In the near future, multi-modal AIs will interact with us via integrated visual, aural and haptic interfaces, for both input and output. The arena for this interaction is two or three dimensional space - be it a document, a virtual reality room, or (most likely) two or three dimensional overlays over the space around us - augmented reality.
It is imperative that humans should have complete control of these digital spaces. The alternative is to trap us without agency within ever more alluring and immersive spaces, which rather than augment our capabilities, will stultify, stupefy, spy on and manipulate us.
Hence, the spaces must be programmable in a deep way. Everything about the space should be programmable, and the response to our programming should be immediate. In other words, we need a live, self modifying system.
…
Much of my career was motivated by a seemingly clear idea that now seems questionable: programming should be easier. In 1968, when I started thinking about this, the pain points were many, and obvious. Programming required mastering many concepts that were outside your domain of interest, like floating point numbers, pointers, and so on (see Note 1). It was hard to deploy these concepts, even if you understood them, again from the point of view of wanting to focus on one’s target problem(s). It was hard to understand what programs would do, once written.
…
What research agenda emerges from these reflections? I’ve sketched two things to think about. What conceptual tools can help people define correctness in the problem domains they care about? What aspects of computation provide intellectual value to those who understand them, leaving aside the value of the ideas for creating programs? Are there ways to embody these aspects in simple, easy to understand forms, so that we plodding meat machines can readily profit from them?
I define a Substrate as:
…
this is available as a lopecode document online
Lopecode is a platform for building and sharing reactive, interactive computational media that can live forever. Itʼs forkable, self-contained, and build-free. It borrows the liveness and expressiveness of systems like Observablehq Notebooks, Smalltalk, HyperCard, Visual Basic, and Spreadsheets—but updates them with web-native technologies and a focus on long-term sustainability. The goal of this statement is to share what I'm exploring, why I think itʼs valuable, and what kinds of projects or collaborations I hope to connect with.
…
In my own research, the concept of substrates started to emerge in discussions with Michel Beaudouin-Lafon, Wendy Mackay, and James Eagan in the early 10s. Michel had, ten years earlier, written a paper on an alternative interaction model to Shneiderman’s direct manipulation that he called instrumental interaction. In instrumental interac- tion, interaction is conceptualised as users manipulating domain objects mediated through interaction instruments. These instruments are described as two-way transducers between the user and domain objects, encapsulating com- mands that can be performed on those objects.
…
How does a substrate differ from a programming system/language? Perhaps programming systems/languages are general-purpose and Turing-complete by default. Substrates, in contrast, can be expected to be specialised for specific domains (e.g. spread- sheets) or to not have a Turing machine lurking within them.
The term “substrate” seems downstream of the view of software as a material or medium. If it is so, then we can work with the material manually; I’m tempted to dismiss “programming” as a specialised field concerned with automating that work. We automate the work that we don’t want to do, but a medium seems like the domain of work that we do want to do ourselves. E.g: communicating or presenting something (limited by the audience’s speed of understanding), or creating / testing some ideas (limited by the author’s speed of understanding).
…
For a long time, programming has been conceptualized as the act of writing code. This view comes with a number of assumptions. Code is written, compiled into an executable and then used by a user who is distinct from the program- mer writing the code. Thinking about programming as interacting with (or operating within) a substrate makes it possible to rethink basic assumptions about programming.
…
The notion of a substrate lets us talk about programming in a way that shifts focus from questions focused on formal properties of programming languages to interaction with a system and capabilities provided to the user. This is more human-centric perspective that, arguably, focuses on what actually matters about programming.
…
I subscribe to Jonathan Edwards' 6 points defining a substrate, but in my vision most of them are not essential definitional aspects, but instead essential possibilities – that is, that the substrate should be designed in such a way that they can be brought into view or “disclosed” idiomatically in a context where they are relevant.
…
A successful substrate needs to solve several other problems for its users. Firstly the notion of errors, especially what were once design-time errors, need to be surfaced in the substrate as it runs. Boxer’s model for this is a good example – a faulty reference for example results in a message displayed on the surface of the substrate which is then navigable to the site of the error. Common reactive libraries offer little support for recognising and propagating these errors, as well as tracing them back to the part of the substrate responsible.
Secondly, we need to deal gracefully with asynchrony – both in terms of operating on asynchronously available data, as well as asynchronous demands for “code” within the substrate as it evaluates. Successful user programming systems do not bother the user with issues relating to whether values are available right now or require I/O which again stems from the faulty reliance on the program stack underlying runtime state. Traditional programming languages make this a viral issue affecting the semantic of the whole codebase as per Bob Nystrom’s What Color is Your Function.
…
My own research has been pursuing two related aims: bringing Smalltalk-style dynamism to a conventional Unix environment, and overcoming the tendency of language to fragment the programming ecosystem. The appeal of dynamism is immediacy, succinctness, flexibility, and its ability to address and explore an open world. The world is dynamic! It respects some but few invariants, is prone to both data change and schema change (or ‘invariant change’!). It is large, but it is explorable given the right tools. A dynamic medium is such a tool—one for first thinking through, and then systematising, an interaction with the world.
Since the appropriate degrees of systematisation and formalisation vary from task to task, it is important that the same medium allows varying that degree. This is also one of many arguments for lessening language barriers: to allow gradual migration to more rigid but more statically tractable languages as the systematisation progresses, including to (in some cases) the prospect of verifiable assurance.
My unusual focus on extending a conventional Unix environment is best explained by defining ‘substrate’ unusually. I will be intending mostly to talk about a hypothetical ‘low-level substrate’.
…
To collaborate while using multiple authoring tools often fails due to the inability to smoothly synchronise content across formats. In this position paper, I tackle a particular angle for substrates, namely substrates for conversion, as a means to support document editing workflows. I first outline major remaining challenges in format synchronisation, which suggest that we are still far from fully resolving these problems. I then identify more immediate interventions to be made to produce actionable results in the short term. Subse- quently, I introduce the concept of floss moves as a way to apprehend individual-scale technical contributions to “substratify” existing artifact ecologies. This approach is grounded in my work on two projects I have been developing in the context of my Ph.D.: Propage and OutDesign, two systems that support the production of multiformat publications in the context of independent book publishing.
Manipulating information with a computer requires reading, transforming and writing that information using a series of constrained encodings in the computer’s memory—information substrates. However, to perceive and act upon that information, humans need to interact with representations and instruments that differ from the encoded information itself—interaction substrates. Reconciling these two types of substrates is difficult: accessing, observing and transforming the underlying digital data is conceptually and technically challenging, especially in the major software architectures in use. To address these difficulties, researchers often suggest replacing various parts of established software with arguably better alternatives, following a modern view of computing. In this position paper, I critique this approach and argue in favour of a more postmodern view of computing, which acknowledges the diversity of computing in the 21st century and encourages research that embraces the constraints that come with it rather than rejecting them altogether. Following this claim, I give examples of modern failures and postmodern successes and present a few research directions that I explored recently and would like to explore in the future to foster discussions and future collaborations on this topic.
My software engineering career has largely been involved in working with multidisciplinary teams in areas such as online learning platforms, medical research teams and homegrown EMR’s in East Africa HIV treatment, breast cancer biobanks, and accessible computing systems. Most recently I’ve been working on modernizing the historical Boxer codebase and preparing it for the next generation. As a result of this I’m primarily interested in helping naive users accomplish daily tasks for life and learning, as well as build interesting new customizations on top of them. My general litmus test is, “Could someone who doesn’t know what Markdown is use this?”
…
Most behaviours, apps, tools – so I think – would be easier to develop, adapt, and integrate if they were expressed as cells and formulas in a programmable doc. The potential of spreadsheet-like docs is far from exhausted.
I envision one huge, versioned, collaborative doc that becomes the de facto operating system of my computer. The doc forms a tree (not a grid) and becomes the new location for most data -- from the system internals, to the user's personal files, clipboard contents, selections, and more. It is cells and formulas all the way down and the SPU – spreadsheet processing unit – hardware makes it fast.
Designing an “SPU” and an OS is a bit too much, so I am now designing something smaller with a more specific use-case in mind. Still, the vision helps guide the design, for it distills various ideas from my earlier work that have worked quite well.
…
To me, the term substrate has always felt frustratingly vague. In trying to define it for myself, I took a look at Wikipedia. A clearer picture starts to emerge:
This tells me that if we call something a substrate, a reasonable follow-up question is: for what? In these definitions at least, the meaning of substrate is closely tied to a specific purpose or process.
I find this notion clarifying. Maybe it's not that interesting to ask, in isolation, whether something is or isn't a (computational) substrate; instead, when we say something is a substrate, we should also discuss the purpose or process.
…
My opinions are based on experience building both academic Smalltalk, Lisp and commercial environments (OTI/IBM VisualAge Smalltalk and Java; Eclipse; Kx Analyst). It would be arrogant to call these substrates, but they were what we had and used at the time. An environment consisted of an open collection of authoring tools; language tools; libraries ( frameworks and components) which supported different domains, through multiple perspectives of the authors and other consumers. They were provisioned through versioning and deployment repositories to geographically distributed team members.
They took more time, did less than expected, and were challenging. They lacked sufficient active external contributors’ viewpoints as well as their resources. In cases such as APL, Lisp, Smalltalk, Java - premature competition resulted in divergent environments which impeded adoption as well as investment in standards and more functional/performant products. More importantly it forced talented research groups to lock into specific environments making it all but impossible to establish deep collaborations.
Unfortunately, these environments are IMO still the most productive for building interesting creative tools. However, tomorrow’s researchers and product developers see little value in stepping back into the 1980s-90s. Those who do often find it difficult to publish and share their work. Those building the newest collaborative creative tools see no path from the promising work in old environments to timely use of these ideas in tomorrow’s product!
…
We use computers to understand phenomena. They are our tools to express, explore, communicate, revise, and refine our ideas. And they can help us simulate possible and impossible futures.
For that, we like to alternate between concrete examples and abstract representations to advance our understanding of complex domains of interest to us. Working out meaningful examples and finding powerful abstractions in their support are not only part of a process but also a means to an end since those examples and abstractions are a manifestation of our knowledge about an area of interest.
We welcome notations that allow us to express our intents directly to help improve our understanding and to communicate and collaborate with others. And while doing so, we refine not only our knowledge about the world but also the ways we would like to talk about it.
…
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” - Conway, 1967
But it doesn’t seem quite sufficient, perhaps software comes to reflect the environment of its development and of its use. This is an indication that the many decades of user advocacy is finally paying off - the user centered design processes of development end up representing the preferences of users to the extent that it slowly shapes the software towards its own end. When engineering companies talk about seeking ‘bake time’ it’s reflecting this instinct that the software that has spent the longest time immersed in the preferences of a population will have accumulated its effect, and so be better suited.
Even software that requires large scale investment, such CAD systems and programming languages, seem to exhibit these properties. Scratch, designed for education, and mass used by children has been a starling success, but the majority of successful no/low-code systems do not use it despite some well funded attempts.
…
There is clearly a great deal in common among the visions (as one would hope). At the same time, there are many divergences, at least in focus. That means there's a point to the workshop as a project: clarifying the areas of agreement and disagreement in what (since there is at least some overlap of aims) can be a useful community.
Having said that, effective communication will be crucial, and there's a long way to go on that. Tomas Petricek points to one of the challenges: the packaging of collections of ideas as demo systems. That emerged for me as a real issue in reading nearly all of the submissions.
On the one hand, embodying ideas in working systems is clearly a valuable test of their workability. On the other hand, doing so makes it hard to evaluate the ideas outside a particular context, or to compare what might be the same, or very similar, ideas that show up in different systems. Dave Thomas points out the challenges to collaboration that resulted from people splitting up to work with different protoplatforms.
…