I like this framing ... But I'll also frame my own project relative to that The vision for Oil (https://www.oilshell.org/ https://www.oilshell.org/) is "Just c

I like this framing ... But I'll also frame my own project relative to that The vision for Oil (https://www.oilshell.org/ https://www.oilshell.org/) is "Just code" + "Just shell", i.e. one other language for "control plane" / configuration / automation. That is, Oil puts all the "glue", which is often YAML these days, under the category of "shell". (This requires adding features to shell, i.e. "the missing declarative part".) The status quo YAML often contains shell, and is sometimes generated by Go templates when logic is needed, so "Just Shell" is simpler. So I basically agree with you that "No code" is ambitious for most problems -- "Just Code" can be better and handles a wider range of problems. But I also think "Just code" is ambitious. Because what do you do about load balancing policies, scheduling policies, authorization policies (collaboration), SSL certificates, backup policies, deployment, build, tests, performance, monitoring, etc. You can try to make it all "data", and that certainly works for many simple apps. But when simple apps are successful (have many users), they turn into complex apps that need control flow, iteration, and abstraction in their control plane, configuration, and custom tooling. In other words, the plain YAML basically never cuts it, which is why you see shell embedded in it, why Go templates generate it, and why people create Lisp-ish languages in YAML (e.g. look at Gitlab / Github CI conditional expressions in YAML; Kubernetes YAML has sequencing and more) Otherwise you get a combinatorial explosion of hard-coded policies in the platform, i.e. a little YAML flag to specify a hard-coded algorithm for every piece of policy that any user could possibly want. Platforms have a lot of heterogeneity their usage patterns, i.e. a power law shape with respect to almost every dimension.