Yea, I have to agree with you that it's an infrastructure problem first. I do think that the trajectory of software and hardware is trending away from "everything happens on one machine". There are still plenty of instances of problems that can be solved on a single machine, but steeped in cloud ideology as I am, I think multi-machine computing is here to stay. Infrastructure may deliver us from the problems of distributed computing, but today most "back-end web"* developers are dealing with arrays that have been split into chunks, and will be for the foreseeable future. *and I don't really know how big this cohort is, or if they've should be driving computing forward anyway!

I find the infrastructure/language separation not particularly useful. I think the problem is a 'system problem' - which doesn't say much but at least does not start by splitting up the system into infra and language. In a sense this infra/language divide is similar to the language/ide divide. We can choose to adopt this POV but will never think of things like Excel. This is a framing of the problem that I think hides other insights. In the broad sense all you have is 'the system'. One machine or multi doesn't matter. And what you are doing is 'negotiating with the system' to have it behave how you want. All negotiation is via back-and-forth messaging. One pattern that emerges is you write these static descriptions of little processes called programs in programming languages and send them off, as one message at a time, into the system. Then separately you send other messages to control (start/stop) the previously defined programs, and yet other messages (yaml etc.) to wire them up. Each of your processes only run on one machine, but the larger logical process (which you never wrote down as a single program) is emergent behavior. Almost all current improvements are trying to incrementally optimize this pattern. Are there other patterns that can be explored instead?

I would think that "emergent" behavior is behavior that emerges (i.e. is discovered or evolves naturally) from patterns of interaction/use with parts of a system. Anything that is just the expected way the entire system must behave (even if it's a distributed system) is not really "emergent". I usually hear others talk about "emergence" as if it's a "divide and conquer" approach to whole system design. I think that's a bad technique in general, because you want your software to be as whole and consistent and possible. (Even with hard boundaries across machines, the impact of that split can be minimized). Anyway, I'm pretty sure that's not the OOP vision of "emergence" that Alan Kay promotes. That's more like "here's some crayons and a canvas" or "here's some forces that can be applied to objects", and seeing where that leads to.

Yes I'm probably using the word 'emergent' loosely to talk about expected behavior but specified somewhat indirectly.

one approach I've seen a few times is to allow a system to be coded (or otherwise specified) as if it were one self contained program, which then either compiles into separate parts, or and acts like a CI/CD/build script which installs or updates separate components on each server.

Dan, I'm very interested in these, if you have specific pointers I'd really appreciate it. The thing I'm really looking for is not specifying 'as a program' but a system that has the notion of update built in as well. (One program that's running distributed gets complicated when you think of updating your program.)

I think WebFlow and Dark both do something like that: https://futureofcoding.org/episodes/035.html https://darklang.com/

Thanks, yes - those two are on my radar 😄