Re^6: Use Getopt::Long even if you don't think you need to

[Aristotle]

I am sorry, but I fail to find any cohesive argument at all in your reply. Before this reply, I thought I understood you to be arguing a particular thing (“command line interfaces cannot carry too much complexity so don’t try to coerce them into complex jobs”), but now I no longer feel I understand at all what you think people should or shouldn’t do nor for what reason or absence thereof.

If you want to argue any particular point, in the interest of clarity, please state it directly instead of leaving it as an exercise for the reader to infer from oblique references.

[BrowserUk]

Sorry, but I don't know if its possible to make my argument any clearer than I've already made it.

If people are considering using GO::L because GO::Std doesn't allow enough options, they should seriously consider using an entirely different mechanism than command lines options to as the interface to their program. If 62 is not enough, it is far too complex to be driven this way.

If it is really necessary for a program with more than 62 configuration options to be command line drivable--as opposed to using (say) a configuration file--then the simple expedient of moving to two character options gives the possibility of nearly 1300 configuration parameters that are still 'packable', just as easy to look up, and if done well, far more memorable.

If people are considering using GO::L because they feel single character arguments are not memorable enough, they should re-consider, because most program usages fall into one of two categories.

1. Regular, often-used: as with tar -xvf ...

   In this case, the user will remember and use the composite argument far more easily than the long option equivalent.

2. One-off uses requiring the user to look up the required arguments.

   In this case, they will have to consult the man page or usage message to decide which options they need to use.

   Once they've done that, the selection of required options will be on the basis of the descriptons, not the option names. And it is far easier to remember or record and then type, single letter option names, than verbose long option names.

   People never remember all the possible long options for any given program, never mind all the long options for all the programs they use. And as is clearly demonstrated by the --no-mudflaps gcc option, and it's several related options; and many, many others, there is little milage in the 'self-documentation' argument either. Even with the full alphabet, and the possibility of multiple words, the originators of that particular optimisation still felt the need to use an obscure and particularly dubious analogy word as the name for the option. No one would ever guess what that option does from reading the long name.

   And that's far from an isolated example. Can you guess what these options do?

   • -mprioritize-restricted-insns=priority
   • -msched-costly-dep=dependence_type

My most frequently used no-short-option, long option, is wget's throttling option. I occasionally use this to allow me to continue surfing with reasonable responsiveness, whilst a long download runs goes on in the background, but sufficiently rarely that I have to look the damn thing up every time I do use it.

Is it --throttle-rate or --limit-rate or --rate or --limit or --rate-limit.

And I am always half way through typing the command before I consider using the option, and then have to abandon what I've typed so far, or start another session, in order to consult the usage.

I really wish that the authors had grabbed a trick from the tail and head tools arsenal and allowed -nn[km] as a short form for that option.

Summary: Long options are rarely a good idea and never necessary. And advocating GO::L "just in case", is a mistake because it encourages the perpetuation of a what was always a bad idea.

Any program for which you feel that more than half a dozen stackable, single character options are likely to become necessary, you should really consider whether there isn't a better way of making those selections.

[Aristotle]

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.

[ysth]

Sorry, but I don't know if its possible to make my argument any clearer than I've already made it.

I, too, completely missed your point until this post. Oddly enough, long options are almost the last thing I'd think of if I were listing the advantages of Getopt::Long. I'd suggest you reread Tom C's post (and maybe some of the others in this thread) with that perspective in mind, since I think you have seriously missed the point(s).

[BrowserUk]

Oddly enough, long options are almost the last thing I'd think of if I were listing the advantages of Getopt::Long.

To summarise, Tom C advocated the use of GO::Long over GO::Std--just in case.

You're advocating GO::Long--but not for the benefit of using long options.

Then, by all means, post your list of GO::Long "advantages", and let me debunk them one by one.

I'd suggest you reread Tom C's post (and maybe some of the others in this thread) with that perspective in mind, since I think you have seriously missed the point(s).

I just did.

• I don't believe I missed his point, I just vehemently disagree with it.
• I stand by my assessment above that long options are a far worse "slip, slip, slippery slope" than even a hand-rolled options parser.
• I see no advantages to GO::Long over GO::Std if you are not going to use long options.
• I see futurism as the modern day curse of software development.

  I don't drive around one-up in an empty V10 pick-up truck on a daily basis, on the off-chance I might see a grand piano going cheap in a yard sale.