Distributed Reactive Programming for Claytronics
July 9, 2019
Programmable matter turns allocation into geometry. A distributed language must choose not only how much computation a program receives, but where that computation lives, which neighboring material it can influence, and how multiple owners coordinate one moving physical structure.
Every Resource Has an Address in Space
malloc() usually chooses any suitable address. fork() usually lets the system choose a processor. Claytronics needs another contract: allocate this region, at these coordinates, beside these neighbors, for this local behavior.
Physical position affects communication, force, motion, power, and the shape a collection of catoms can form. The language therefore exposes location as a computational resource instead of hiding it behind a scheduler.
Ownership Turns Contention Into Cooperation
Two people can move one box efficiently when each takes a side and both agree on the direction. Two programs need the same clarity. One owner may control the left region, another the right, while a shared protocol coordinates the seam between them.
The system tracks whether a region remains available, reserved, managed, damaged, or lost. Those states let local programs adapt without asking one global controller to understand the whole physical object.
Code and Material Share One Vocabulary
When code and data use the same reconfigurable material, resource type becomes homogeneous. Geometry, ownership, availability, and current configuration distinguish one allocation from another. Reactive updates then move through local relationships as the physical structure changes.
Florian Myter’s underlying-layer work supplied one starting point. A high-level language can build above it by making spatial agreements composable and visible.
Build the Next Layer
The next opportunity lies in a language that can reserve regions, transfer control, recover from lost cells, and coordinate motion across many local owners.
LinkedIn status when archived: Visible to anyone on or off LinkedIn.
Designing a distributed reactive programming language is the major stepstone on the long path to scalable Claytronics (programmable matter).
Resource allocation could (and should) be made explicit in a distributed programming language.
When programmer is aware about exact size and locations of available resources, efficient management of these resources becomes possible.
Imagine allocating chunks of memory in malloc() not only specifying size, but exact address, where the chunk should be allocated. Imagine calling fork() and specifying exact core (or even remote location).
In our computing model, code is data, and data is code, so the type of resource is homogeneous. Only geometrical physical location is left, and the fact that the resource is available / managed / or was lost etc.
A great work was done by Florian Myter on the underneath layer https://lnkd.in/gwSU_Q4
We need to explore high-level design for the language where distributed management of resources can be agreed upon over shared access to areas of influence.
Imagine working on moving boxes with your friend. You can agree that your friend will be moving the left part, and you'll be moving the right part. Without the agreement, you experience a lot of "resource contention"...