ya, we're kinda talking about the same stuff. I appreciate the list of examples.

I have some ideas about how to do this, and I think the basic building block is something like "a partially specified object". For example, suppose you want to write a CLI application. The normal way to do this is write a bunch of, say, Python code that processes the args, does the thing, writes the outputs, prints the help, etc. I think there is a different architecture where you say:

1. I want a CLI application. Okay, this sets up a scaffold with all the parts unfilled out. It doesn't "compile" at the moment but you can still run it and inspect it using something akin to devtools / a visual inspector/debugger, kinda like a level editor in a game engine's authoring tools (picture Unity's editor).

2. next I fill in the commands that I want to run. These have a type (provided by the parent application), which is a union of all the things that that a CLI application can do (flags, args, etc). the CLI library translates these to function calls that don't do anything yet. Now I can call all the commands, print the help, etc, but they don't do anything.

3. Next I implement all the commands, etc.

Now this is all isomorphic to writing a bunch of files of code. But my feeling is that you want to be writing the code by authoring the data structures directly. You have a pre-existing type for "CLI application", and you fill in all the slots. Each change is a diff at the level of the data structure. There's some internal code for how you do the things, but those are calls out into functions that are potentially in another language. Diffs and etc are at the level of the data structure itself, not the underlying code (or rather: the underlying data is code, but the visualization of the diff is in terms of how the data structure changed, not how the code changed).

The goal is then to find a way to generalize this method of authoring across all software, to do it very generically so that your "IDE" is a tool for visualizing abstract applications, of which common architectures (CLI app, library, GUI application, server, website) are just particular libraries, and in which the compilation process turns the thing you're authoring into an actual application in an existing programming language (which is now treated as a data format, like assembly code, rather than the actual language you author things in).

Yes, what you describe is similar to other ideas I've had in past. Not necessarily in the specific steps you mentioned but the idea of "I want a CLI application" and the tool I'm using sets up the high-level scaffolding for a CLI application in terms of "CLI application" concepts rather than working at the level of splitting strings or whatever.

"argparse"-style libraries are actually a good example of climbing up the abstraction ladder where you're talking in terms of CLI concepts. But they're usually implemented either as messy metaprogramming hacks or as function/method calls and callbacks.

Instead of doing this, one can imagine editing a data structure, visually, that represents the same information, e.g., I have a treeview of all the subcommands my application supports, I can filter them, I can edit their help information with color like in a wysiwyg editor or markdown instead of writing into string literals on the app, etc.

You did mention that this high level scaffolding wouldn't compile or run, but I don't think that's necessary. Just have it compile and run right away, but simply do nothing useful. As you fill in the pieces it starts doing things.

Incremental development is extremely important or you end up in a UML situation where the intended structure of the program and the real constraints the program is under don't match.