Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

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

by Aristotle (Chancellor)
on Jun 11, 2008 at 02:07 UTC ( #691371=note: print w/ replies, xml ) Need Help??


in reply to Re^5: 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

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.


Comment on Re^6: Use Getopt::Long even if you don't think you need to
Re^7: Use Getopt::Long even if you don't think you need to
by BrowserUk (Pope) on Jun 11, 2008 at 05:13 UTC

    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.


    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.

      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.

      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).
        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.


        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://691371]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2014-07-31 01:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (244 votes), past polls