|
in reply to Re^3: Use Getopt::Long even if you don't think you need to
in thread Use Getopt::Long even if you don't think you need to
So what you are trying to say is that people should hand-hack their option parsers just so they do not get into the temptation of using the command line to pull more weight than it can?
Or if not, and your argument is a different one, then what ever relevance does it have for this thread?
Makeshifts last the longest. |
Re^5: Use Getopt::Long even if you don't think you need to
by BrowserUk (Patriarch) on May 26, 2008 at 09:59 UTC
|
So what you are trying to say is that people should hand-hack their option parsers...
No. You are the only one who's mentioned anything about "hand-hacking". I refer you to my earlier comment regarding "a lack of imagination".
... then what ever relevance does it have for this thread?
Ditto. Relevance:
Use [big thing] even if you think you only need [small thing]
Use a trailer even if you think you only need to pick up a pint of milk occasionally.
Use a Mack truck even if you are only picking the kids up from school.
Use a Howitzer even if you are only swatting a fly.
I deliberately didn't suggest any alternative, because the alternatives are already implicit in the title. Whatever you might have used that you are being encourage to drop in favour of GetOpt::Long, is one possibility.
That might, for example, be GetOpt::Std. That's restricted to 62 options...sooo limiting...not.
Now you are considering responding with the old saw that: long options are more descriptive and easier to remember. And that is just plain wrong. (YAJ) What do you think --Wno_mudflaps does?
Or in the context of a recursive HTTP download tool, what do you think the word 'spider' means? Now, how does what you think it means, fit with the description of the wget --spider switch: "don't download anything". Intuative?
I, in common with thousands of others, use the command tar -xvf archive.tar on a regular basis. I could type that as tar --extract --verbose --file=archive.tar, but I don't. And nobody I know does. Why would we?
Until I just looked them up I wasn't 100% certain that I knew what they actually did. But it doesn't matter, because I don't think of that as a command with three options. I think of it as as single command. It could, for all practical purposes be tar-xvf archive.tar.
And don't take any of that to mean that I am pro-getopt::std per se. The whole 'command line switch options as sub-languages' is a (well documented) complete mess. But like many other ingrained ideas, the begats and seven days amongst them, it is unlikely to go away any time soon.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
|
|
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.
Makeshifts last the longest.
| [reply] |
|
|
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.
- 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.
- 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.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
|
