Already Existing External Protocols

2026-02-19

Computer science is still working out how to deal with asynchrony. Humanity has been doing it for a long time.

Contemporary programming notation is largely built on synchrony as its foundation — the CALL/block/RETURN model, where execution stops and waits. This makes asynchronous operation feel like a special case, something to be handled with extra machinery. Callback hell is one symptom of this. The difficulty of reasoning about concurrent systems is another.

But outside the terminal window, human civilization has been managing asynchronous, autonomous, independently-operating agents for centuries. The solutions are familiar, intuitive, and often invisible precisely because they work so naturally. It’s worth pausing to notice them —and to ask what programming notation might look like if it started from the same assumptions — and whether we can get there from where we are, without starting from scratch.

The handshake.

When two people meet, they shake hands. It’s a small ceremony, but it encodes something important: an acknowledgment that two parties who were previously operating independently have now, briefly, synchronized. The handshake is the rendezvous protocol. What makes it meaningful is exactly that it’s special — it marks the transition from async to sync, rather than assuming sync as the default. In a world where everything was already synchronized, the handshake would carry no information.

The broader lesson: fundamental asynchrony leads to simpler solutions in general, with specialized synchronization protocols only when they’re genuinely needed — rather than paying the synchronization tax on every operation.

“Begin the meeting on time, even if not everyone has shown up.”

This is a familiar rule of professional courtesy. It’s also the operating principle of distributed systems that must make progress without waiting for universal consensus. Blockchain formalizes it. But the intuition is older and more ordinary: the system advances on what has arrived, not on what might eventually arrive.

Corporate org charts.

Every organization that has grown to significant scale has converged on the same structural insight: trees, not graphs. Requests flow down; results flow up. No going over the boss’s head. No micromanagement reaching past intermediate levels. Each node in the hierarchy presents a well-defined interface to the rest of the organization while keeping its internal workings local.

This is encapsulation and hierarchical decomposition — ideas that software architecture values highly. Organizations arrived at them through hard experience with what breaks when you don’t have them.

The relay race.

Token-passing networks. Pipelines. The baton moves forward through a sequence of runners, each operating independently. No runner controls any other. The protocol is minimal: receive, perform your leg, pass it on. The elegance of the relay race is that coordination emerges from the structure of the handoff, not from any runner watching or waiting for any other.

Functional notation cannot simulate this without extra work. Callers block and wait for callees to return a result. Functions are tightly coupled by definition. Functional notation implies synchrony. It does not imply asynchrony.

Petri nets and the post office.

Successful scheduling — and rescheduling — assumes autonomous operation of actors. Most operating systems understand this and implement processes as asynchronous units with their own state and execution context.

The post office understood the same thing long before computers existed. Mail is not handed directly from sender to recipient. It flows through intermediaries, each one autonomous, each one doing its job without knowing the full end-to-end journey. A letter with a return address is a packet. The postal network is the internet. The protocol scales across continents because no single actor needs to coordinate with every other actor — they only need to know the next hop.

The internet itself uses fire-and-forget as its native protocol: send, attach a return address if you want a reply, move on. Remote Procedure Calls came later, as a way of imposing CALL/block/RETURN behaviour onto a distributed system that wasn’t built for it. There are cases where that’s the right tradeoff. But it’s worth being clear that it is a tradeoff.

The production line.

Conveyor belts encode a practical insight: order of arrival matters, and the line doesn’t stall because one station is momentarily busy. Items queue. Stations process. The line keeps moving. Queuing theory and pipeline architecture formalize this — and give us useful tools for analyzing it — but the underlying intuition is older and more physical than the mathematics.

Piano lessons.

Hard real-time systems have strict deadlines. Notes must arrive at precisely specified times, or the music falls apart. Music notation has been solving this problem for centuries — and five-year-olds learn to read it. The notation makes time a first-class entity. Duration, rhythm, and synchronization between voices are all expressible directly, naturally, without ceremony.

The functional programming tradition has tended to treat time as a second-class concern — something to be worked around rather than expressed. Monads and explicit state threading are powerful tools, but they are workarounds for a notation that wasn’t designed with time in mind. Music notation suggests that a notation built around time from the start doesn’t have to be complicated. Children learn it.

The stack of plates in a diner.

The spring-loaded plate dispenser is a stack — last in, first out — and it predates computer science by a considerable margin. It’s genuinely useful for plates. Computer science recognized the structure and found it useful for many other things, including the call stack that underlies function call execution.

The plate dispenser is useful for a specific purpose. The question worth asking is whether we have perhaps leaned on the stack more broadly than its strengths warrant — and whether other structures, equally familiar from everyday life, might serve some of those purposes better.

The pattern.

Each of these examples shares a common substrate: autonomous agents, asynchronous operation, message-passing, queues. Civilization arrived at these structures by building things that had to work at scale, across distances, without central coordination.

Computer science has studied and formalized many of them — and the formalization is valuable. But somewhere in the process of formalization, these structures may have come to seem more exotic and technical than they actually are. They are not exotic. They are how things work when they work well.

The suggestion here is a mild one: when programming notation makes asynchrony feel difficult, it may be worth looking at how the problem has already been solved — not in research papers, but in post offices, relay races, and meeting rooms.

See Also

Email: ptcomputingsimplicity@gmail.com

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/65YZUh6Jpq

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html