#Terminology bikeshed fest

1 messages · Page 1 of 1 (latest)

tardy basalt
#

🧵 right this way bikeshedders 🙂

polar shale
#

I do think these are more intuitive

polar shale
#

What about just commands instead of cli/clis? Feels more aligned with functions and checks, and it already even calls them subcommands. (I think I saw a thread on this with @scarlet coral recently, but I didn't see how it concluded.)

I like the simplicity of being able to start with a flat set of commands [foo, bar] and then refactor them into separate hierarchies if/when I need to by simply nesting them under a new toplevel command (daggercli > [foo, bar]). In small projects I would likely never need to take that second step. You can think of the entire environment as being the 'root' of the CLI.

tardy basalt
#

I also like commands, just not as much as cli. I have two issues with commands:

  1. It's ambiguous whether it's a user interface (something you call from the terminal) or a programming interface (something you call from code). It's especially important to remove this particular ambiguity, because it's a key aspect of the zenith design compared to its predecessor "project commands". We need it to be so clear, that people can quickly decide if they like it or not, and tell us clearly. With command I worry that they'll miss this important aspect of the design, and we'll miss out on the feedback. cli on the other hand makes it clear that it's a user interface and not a programming interface.

  2. It feels more tightly coupled - like the whole environment is one big CLI with a bunch of subcommands. It feels less natural to import more subcommands from other environments, and stitch them in. With cli the loose coupling is more visible: an environment contains a collection of CLIs, and you can import CLIs from other people's environments. It's slightly more overhead for very simple environments (I get your point; nobody has to worry about what to name their Makefile), but I think it's worth it, and also easy to solve in practice. For example for simple environments that have only one CLI, there can be a convention of naming your CLI after your environment. Or we could allow one unnamed CLI, which would make it the default. Something like that. Lastly, a cli would just have a root command, so the Command type would actually exist, and include subcommands like it does today.

polar shale
#

re 1, I guess I don't ever think of programming when I think 'commands', it always means user-facing CLI, so this point doesn't resonate much with me.

re 2, I see your point. Do you have examples of scenarios where you would want to import CLIs from other environments? (Not that I doubt it, just finding it hard to relate.)

tardy basalt
#

for point 1: yeah I guess that might be mostly the bagage of our recent use of the term (ie. in "project commands") but not really relevant to our future audience who own't have heard of that

bronze crag
#

Instead of CLI / Commands, could tasks be a good option?

scarlet coral