Both imperative and declarative programming require an understanding of the domain you’re trying to code a solution in. Once you’ve understand the model, the DSL makes a lot more sense. I strongly believe that people who are hoping for these no-code tools don’t care to understand the domain, or why it’s formal representation as a DSL is necessary. What makes natural language great is the ability for humans to create a shared model of understanding that aims to eliminate ambiguity. And even then, there are issues. Formalism is what solve these issues, not piling on more random factors.

It's true that no-code tools have mostly not been that successful in the past (except in very limited circumstances), because eventually you run into cases where it would've just been easier to just write some code than to try to finagle the no-code constructs into doing something it wasn't really designed to support. Often the most compact way to specify something is actually just they Python code itself, for example.

> What makes natural language great is the ability for humans to create a shared model of understanding that aims to eliminate ambiguity.

I'd say that natural language enables shared understanding because it *allows* ambiguity. We can construct abstractions and find analogs to put them into words. We expect the hearer to reconstruct those abstractions from a different starting point and by referring to a different set of experiences. The potential for ambiguity is a necessary part of that process. We get closer to a reliably shared construction by layering our analogs and testing our respective mental models against each other.

Formalism and DSLs definitely do a better job by giving us an initial set of shared meanings to work from. An LLM might be able to wrap a fuzzy interface around a DSL but I agree that sharing a common semantic framework without fuzzy mediation might be a much better idea.