Indeed! In fact it is so solved that the Python standard library has solved it differently 3-4 (I've lost count) times already, let alone the dozen or two extra packages at PyPI ;)
I recognize that many people are not willing to use C++, and among those that are, many are still unwilling to use Boost, but I find the program_options library to be great. An example use that I think is reasonable and a big win over doing it myself: https://github.com/scotts/cellgen/blob/master/src/main.cpp#L...
I can appreciate the subtlety of wording, but in reality it is more of
> many will never be touching Boost even with a long pole and for a large sum of money
:)
I respect people's decision, I guess I just don't understand it.
That said, boost is a dependency that pays off in terms of programmer time if what you're doing is complicated enough (in other words, if you think you might reimplement some part of boost, you're better off using it as a dependency instead.)
Use your language's command-line option processing libraries.
OptionParser in ruby and argparse in python. There is no reason to eschew these libraries: they're part of the standard library, they require zero coupling to your app logic, and they handle all of the edge cases for free.
"But I can just shift the arguments", you say! Yeah? Great! What if the user pipes input through STDOUT? What if the user passes a flag, a required argument, and then another flag? Will your script read the last flag correctly, or has the naive logic already entered "required argument processing mode"? Just use the library. It's a solved problem!