Node-based programming is usually done on a two-dimensional canvas. What if it were done in a three-dimensional space? Spatial Nodes is a visual programming language for creative coding in virtual reality that tries to answer this question. Users can build interactive and animated worlds by connecting and manipulating nodes directly with their hands. The nodes are evaluated as the user modifies them, so the result of the user's action is visible on the scene in real time. The project shows how programming can become a spatial and embodied activity. It identifies some challenges in creating this kind of a programming environment, such as interaction design and debugging, and suggests that example scenes can be an effective way of learning how to use it.

Software testing can be hard. We've got IDEs, time travelling debuggers, and static analyzers but printf debugging is still a tried and true technique. Imagine you're on the trail of a vexing bug; you suspect you know which function is responsible. Well, you can add debugging code, but you still have to get the program to go there; if the function is nested, there's no name main() can call to get there. And you can't just GOTO that code because it's harmful. Luckily the COMEFROM language solved that problem by allowing code at the destination to initiate a transfer of control. What COMEFROM didn't solve was constructing the context necessary to figure out what's going on deep in the guts of your program. Instead, when you're hacking the suss function, just say COMEHERE:with(<context>). I'm demoing a variant of JavaScript that adds COMEHERE to automatically drive control deep into a function to make interactive testing and debugging easy. If you want your programming language to be easy to interactively debug or would like a semantics that allows turning the results of that interactive debugging into unit tests for implementation details deep inside nested functions that can specify inputs to outer function calls, then COME_ON_OVER to my talk!

Perhaps to build systems that are malleable and end-user programmable we need to rethink the relationship between runtime and development artifacts. It is our opinion that treating source code as the primary development artifact was the original sin that placed a one-way door between developer and user: when a saved format is authoritative, the tools that read and write that format are privileged, and everyone on the far side of the door is a user. Lopecode is source-last: there is no external source code; the canonical representation is the live executing system. When source code is needed, functions are decompiled on demand starting from Function.prototype.toString(). Serialization becomes a projection to one of many formats: a standalone HTML file, a JavaScript IIFE or an ATProto PDS. Format-independence is a consequence of runtime-primacy. Because no format is canonical, editors, exporters and carriers are unprivileged userspace modules — a plurality of non-source editing surfaces that can be added after the program has started, without coordinating with each other. We share three field episodes where the consequences of Lopecode's format agnosticism shone: shipping a tool into a locked-down corporate environment; liberating a running program from a notebook SaaS; and tunnelling an AI investigator into a third-party website.

On a canvas, objects are live. Objects are directly arranged and modified, connections are created between them, and the result is visible immediately. We do not see this with the background. Plena asks what a canvas would be if the background were live too. I explored this question in the context of visual research in art and design fields: collecting images, spreading them out, annotating them, rearranging as one’s sense of the material shifts. This work relies on unclear, ambiguous ideas and keeps shifting its direction – qualities that rigid systems often fail to support. For Plena, I chose “field” as a core conceptual metaphor for designing the representation of and interaction with programmable background forces. The background of canvas becomes selectable points, to which new vector fields can be assigned. A membership field, drawn as soft-edged gradient blobs, gives each object a graded membership value in a color tag rather than a binary one. A velocity field, drawn as vectors, continuously updates object positions. Fields prevent canvas from settling, and I explored some of the benefits of this.

The design of general-purpose visual programming languages where one programs by demonstration is an ongoing challenge, particularly when limiting escape to text-based editing. The author reframes this challenge by coining the Prague Correspondence Problem: Can we draw a rigorous relationship between instructions that execute in a virtual machine, direct manipulations or gestures that communicate those instructions to a virtual machine, and visual representations of these instructions executing that the machine may communicate back? Deixis is an in-progress prototype of a live visual coding environment. A user can directly demonstrate the execution of a graph-rewrite algorithm the way they want it to run. The nodes are symbols and include first-class operators, making Deixis visually homoiconic. The edges are spatial relations between nodes determined by matching on and transforming node arrangements. Its visual virtual instruction set architecture includes a base set of graph-rewrite instructions, such as creation, moving, and evaluation. Each is associated with an interaction and a visual that is concurrent with execution. A user can demonstrate programming factorial. It remains unclear what models exist for conceptually and practically unifying computing with associated visuals and direct manipulation—where direct manipulation is execution, and where its corresponding visual representation is execution as well. Deixis suggests a path toward another model by using ideas from linguistics, such as imbuing spatial arrangements with syntactic structure. Deixis aims to advance the Prague Correspondence Problem by making visual structures interactive and executable.

Concatenative programming languages offer attractive ergonomics for some applications, but are also sometimes called "write-only languages" because programs can fall into convoluted stack-juggling that is difficult to follow. Rewriting systems also offer some very straightforward expressions of some classes of problem, but face complex workarounds in others. Many of these strengths and limitations are complementary: advanced multi-step stack-juggling is complex and hard to follow as concatenative functions, but would be trivially expressed as rewrites over the stack, while rewriting systems often make negation and ordinal comparisons complicated. Here we present a multi-stack concatenative programming system operating over a rewriting substrate: functions can be defined in conventional concatenative style, or as rewriting operations, or even combinations of both, and all application proceeds by rewriting the remaining program and state. In doing so, new possibilities for run-time intervention are exposed: the program can be paused and both state and pending code can be edited, including the equivalent of the call stack, but yet more dynamic options are also available, including evaluating other programs ad hoc *within* the main program's state. We also identify bindings between program-level stacks and external resources that can allow bidirectional direct manipulation of visible state.

What happens when a programming language does not have variables and even the function parameters are without names? For sure, code becomes unreadable due to the cognitive load of imagining and keeping track of data transformations. A good solution is to work in a live REPL. In this talk, we will describe a concatenative functional language and demonstrate how an interactive coding environment turns unintelligible code into the easiest programming language to learn. We also mention why would anyone use a language in which every sequence of symbols is syntactically valid.