Physical Constraints Belong in the Program
A distributed program does not run in an abstract place. It runs across CPUs, GPUs, FPGAs, network links, memory regions, clock domains, device drivers, queues, and control paths. Those physical facts affect latency, throughput, failure, security, and who owns each piece of state.
A useful programming model should let the builder express those constraints directly instead of hiding them behind a flat worker abstraction.
Placement Is Part of Meaning
When a program spans devices, placement is not an optimization pass at the end. It changes what the program means operationally: where data waits, which clock observes it, which link can fail, which host can restart, and which region is allowed to mutate state.
That is why heterogeneous systems need language and runtime support for physical boundaries, not only faster kernels.
Useful Scope
The original post linked Adrian Sampson's FPGA abstraction writing as immediate context. The continuing question is how to make placement, resources, and physical costs readable without forcing every project into one accelerator-specific programming style.