To have two different things you need to run, now you need to have multiple copies of the same thing.
What does the parsing? How do you split out a URL, what order are the "flags" in? Do you have named arguments, etc? Well now you need to have your own custom parsing library instead of just using exactly what anyone else would use.
Where do you go for help? Do you rename it to my_program_help.exe then rerun it?
What about chaining things together? Anything dynamic? Is the caller script expected to rename your program before running it?
> fetch---api.github.com---repos/owner/project---q=stars>100---o=json.exe
Oh lord.
> Imagine install_PY3_MODULE_NAME.exe. It reads the filename, extracts the Python module name, downloads dependencies, sets up Python if needed, and creates a launcher. Rename it, and you have a new installer for a different project. Icons, mirrors, or other metadata can also live in the file as resources – all self-contained, all shareable.
Imagine changing that to "install_python.exe --module module_name".
The thing you really want to do instead is have a single executable, then have scripts or even aliases that are named for what they do that are super thing wrappers. One copy, no moving, renaming, anything.
`fetch---api.github.com---repos/owner/project---q=stars>100---o=json.exe`
and 50 different copies for various different projects, is replaced with
`fetch.exe`
and
`top_100_github_repos.exe`
`highest_rated_github_repos.exe`
`get_weather.exe`
Which are single line scripts that pass on arguments to the base program. Which also means you can fix any issues in one place.
Instead of doing foo --bar you are now doing ln foo foo--bar && foo--bar. It's less efficient on the file system level. It's less efficient on the program level. It's less efficient to type. Why
IMV it's a clever trick, and like you my instinct is that if I attempted to integrate this into my own workflows, I would endure some sort of hardship down the line but it's not immediately obvious when or how. Or maybe for certain things it would be fine and less painful than other options, like other similarly clever tricks I felt uneasy about at first
And good luck trying to run the same programs with different arguments. You'll have to take turns renaming the file, or create hardlinks just for ephemeral arguments.
It can be useful but there's time and place to do it.
> And good luck trying to run the same programs with different arguments
I don't read the idea as trying to replace arguments as in remove, "don't ever use arguments anymore", but as a DSL for _allowing_ to pull supported arguments into the filename. Basically an args list preprocessor. That would only take away your freedom of including triple-dashes in your file name without there being consequences.
This smells like an XY problem