Day 13: Séance vs. the world

I suspect most developers would agree that having good software architecture is important. They would start to disagree, however, when defining what software architecture is and what would it make good. A popular definition is that something is architectural if it is important and hard to change. This makes it clear why choosing the right architecture is key: it is a persistent force-multiplier on future work.

I like this definition well enough, but I would like to tweak it slightly. The part of a software system that most influences its resistance to change is the mental model of the people who would change it. This is not a new idea, I stole it from Programming as Theory Building , but I don’t think it is given sufficient consideration. When you enter a building, the aspect of its architecture that most affects your experience is emotional: do you feel promptly guided or free to linger? How much light is there, and where does it come from? Is it imposing or nurturing? Was it built with a functionalist philosophy, where the space tries to disappear, or was it built to communicate a set of ideals? This last distinction applies especially to software architecture: the construct is shaped by the ideals of its builders, and reflects those ideals outward both to the people using it and to the builders themselves.

This is all to say, I think there is an aesthetic aspect to choosing an architecture, and aesthetics have powerful influences. Here I will describe my plan for Séance’s architecture, and the ideals it aims to reflect. I begin with the blueprint.

State actors

struct ExecutionState {
    config: Option<Config>
}

trait World {
    fn act(&mut self, action: Action);
}

impl ExecutionState {
    fn new() -> ExecutionState {
        ExecutionState { config: None }
    }

    fn init(&self, mut world: impl World) {
        world.act(Action::ConfigLoad);
    }

    fn receive(&mut self, message: Message, mut world: impl World) {
        match message {
            // ...
        }
    }
}

enum Message {
    ConfigLoaded
}

enum Action {
    ConfigLoad
}

This design pulls from several sources, both technical and philosophical. The closest progenetors are the designs described in sled simulation guide (jepsen-proof engineering) and The plan-execute pattern, where the goal of the design was to be thoroughly testable and to isolate asynchrony. These goals are also my own: thoroughly tested, pure, deterministic systems tend to be the most reliable, and those that I personally find the most relaxing to work on. Both are similar to the actor model, and are arguably forms of closed-loop control.

Visibility of system status

This design also resembles the Elm architecture, and so would fit naturally into a visual UI. This is a secondary part of my goal: visibility of system status is a core priority in the field of UX. A similar point is made in the original Permacomputing manifesto: Computer systems should also make their own inner workings as observable as possible. If the computer produces visual output, it would use a fraction of its resources to visualize its own intro- and extrospection.. It is no coincidence that the properties of permacomputing systems (accessibility, flexibility, resilience, efficiency, and compatibility) have been a recurring theme in these updates. They are the lens I used to approach software.

To this end, I plan to add a TUI to Séance that will make its view of the world fully visible. To do so, I have designed its architecture around a state in a pure state machine. By visualizing this object directly, I ensure that there can be no mismatch between appearance and behaviour. Each update to the inner state can similarly trigger an update to the visualization. In a perfect world, this would include everything: DNS lookup status, packet loss, retries, etc. Séance’s output could almost be a network diagnostic tool! But doing this all at once would be boiling the ocean. To start, I hope to display each file that is being fetched and its progress as it is downloaded and transformed.

This architecture is also weird; I’ve never worked on a system that commits to anything like it. But that’s why I’m excited to see how it goes, as an experiment. What else are adventures for?