Ah, so you are talking about long options. Thanks for clearing that up. I have two responses:

1. I disagree with the premise.

   Sure, in interactive use, long options are pointless.

   However, I also write shell scripts on occasion, and then it is quite useful to use the long options of a command I don’t use routinely, as it makes it quicker to re-read the script when I open it again 2 years from now. Trying to avoid writing comments whenever it is possible to make the code sufficiently self-descriptive is a strategy that’s served me excellently in general.

   Yes, long options aren’t necessarily any more self-explanatory than short ones. But that depends on the scope and focus of the tool; if it does one thing well, more likely than not you can choose useful names for long options.

2. Getopt::Long can parse short options too. Once upon a time it could not (which led to Getopt::Mixed), but that hasn’t been the case in forever.

   Why would one do that? Because the API is much better:

   • It allows much more specific declaration of the values a switch can take. This means I can write less code – and if it’s just validating whether the argument the user actually passed is a number when I need a number.

   • It allows stashing values in arbitrarily named variables rather than just a hash with single-letter keys. I don’t know about you, but I find my programs more readable when my variables have useful names.

Makeshifts last the longest.