|
|
|
|
|
by sirwhinesalot
235 days ago
|
|
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. |
|