On Sat, 2016-05-14 at 07:34 +0300, Andrei Alexandrescu via Digitalmars- d wrote:
> […]
> What are those and how are they better? -- Andrei

C: argp, GNOME CLP
C++ Clara, gtkmm CLP
Python: argparse
Groovy: Commons CLI wrapper
…

the list is quite lengthy.

A table of data declaring all the things. No messing round with control flow during the parse. Automated message construction. Use of properties and data structure for all the results.

Basically an increased level of abstraction. Imperative → Declarative.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu wrote:
> On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote:
>> getopt is a 1970s C solution to the problem of command line parsing.
>> Most programming languages have moved on from getopt and created
>> language-idiomatic solutions to the problem. Indeed there are other,
>> better solution in C now as well.
>
> What are those and how are they better? -- Andrei

Since no one has mentioned Vladimir's funopt yet:
https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt/

On 5/14/16 10:44 AM, Russel Winder via Digitalmars-d wrote:
> On Sat, 2016-05-14 at 07:34 +0300, Andrei Alexandrescu via Digitalmars-
> d wrote:
>>   […]
>> What are those and how are they better? -- Andrei
>
> C: argp, GNOME CLP
> C++ Clara, gtkmm CLP
> Python: argparse
> Groovy: Commons CLI wrapper
> …
>
> the list is quite lengthy.

I showed a fellow programmer std.getopt. We were both on laptops. He wanted to show me how good Python's argparse is and how D should copy it. By the end of the chat it was obvious argparse was much more verbose and less pleasant to use than getopt. Like you have to create an object (?!?!) to parse the command line and many other lines of nonsense.

> A table of data declaring all the things. No messing round with control
> flow during the parse. Automated message construction. Use of
> properties and data structure for all the results.

Where is the control flow in

bool frob, meh;
getopt(args,
  "frob", "This is the frob", &frob,
  "meh", "That's the meh", &meh);

? Honest question.

> Basically an increased level of abstraction. Imperative → Declarative.

I'm not seeing the imperative here. Care for a concrete side-by-side comparison? Pick your cherries.


Andrei

On Sat, 2016-05-14 at 16:17 +0300, Andrei Alexandrescu via Digitalmars-
d wrote:
[…]

> I showed a fellow programmer std.getopt. We were both on laptops. He
> wanted to show me how good Python's argparse is and how D should
> copy
> it. By the end of the chat it was obvious argparse was much more
> verbose
> and less pleasant to use than getopt. Like you have to create an
> object
> (?!?!) to parse the command line and many other lines of nonsense.

"verbose", "less pleasant" and "nonsense" are hardly the right terms unless the intention is to try to convince us using advocacy research.

D will have whatever option parsing the people prepared to put in the effort and have the permissions and rights to add to the codebase want.

Of course the more "democratic" way forward is to remove command line parsing from the D distribution and have it in the Dub repository as a package. Then there can be many different ways of doing things and statistics of downloads can be used to decide which is preferred.

This reminds me that SCons (and indeed CMake) probably need ways for specifying dependencies and retrieving them from the Dub repository, so that the Dub program is not needed.

> > 
> > A table of data declaring all the things. No messing round with
> > control
> > flow during the parse. Automated message construction. Use of
> > properties and data structure for all the results.
> Where is the control flow in
> 
> bool frob, meh;
> getopt(args,
>    "frob", "This is the frob", &frob,
>    "meh", "That's the meh", &meh);
> 
> ? Honest question.

I thought we were talking the C library which advertises http://www.gnu .org/software/libc/manual/html_node/Example-of-Getopt.html#Example-of- Getopt as the official example and exemplar of getopt use.

> > 
> > Basically an increased level of abstraction. Imperative → Declarative.
> I'm not seeing the imperative here. Care for a concrete side-by-side comparison? Pick your cherries.

See above: looks like a stonking great while loop to me. However if your use of getopt is different from that above, I can see that this argument is taking place by two people observing two completely different things, and is therefore not a discussion or an argument, but a point for a reboot of the thread!

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 14 May 2016 at 14:29:04 UTC, Russel Winder wrote:
> However if your use of getopt is different from that above, I can see that this argument is taking place by two people observing two completely different things, and is therefore not a discussion or an argument, but a point for a reboot of the thread!


Indeed, D's getopt is almost nothing like C's getopt aside from the name - it is a from-scratch implementation more inspired by Perl than by C.

from the docs:

"Credits

This module and its documentation are inspired by Perl's Getopt::Long module. The syntax of D's getopt is simpler than its Perl counterpart because getopt infers the expected parameter types from the static types of the passed-in pointers."

On Sat, 2016-05-14 at 15:14 +0000, Adam D. Ruppe via Digitalmars-d wrote:
> 
[…]
> Indeed, D's getopt is almost nothing like C's getopt aside from the name - it is a from-scratch implementation more inspired by Perl than by C.

I claim then that Andrei misdirected me by asking about C command line parsing. Also having a name other than getopt for the D thing would avoid these sort of misunderstandings. Whoever wrote the D CLP chose a poor label for it in my view.

I would still prefer a data-oriented rather than opinion-oriented discussion of Python argparse vs. D getopt if there is to be a compare and contract debate.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2016-05-14 12:31, Marc Schütz wrote:

> Since no one has mentioned Vladimir's funopt yet:
> https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt/

Looks really interesting.

-- 
/Jacob Carlborg

On Saturday, 14 May 2016 at 13:17:05 UTC, Andrei Alexandrescu wrote:
>
> I showed a fellow programmer std.getopt. We were both on laptops. He wanted to show me how good Python's argparse is and how D should copy it. By the end of the chat it was obvious argparse was much more verbose and less pleasant to use than getopt. Like you have to create an object (?!?!) to parse the command line and many other lines of nonsense.
>
I've found D's getopt package to be pretty good. There are a number of small things that could make it quite a bit better. To me these generally appear more the result of limited usage rather than anything fundamentally wrong with the design.

For example, error text produced when a run-time argument doesn't match the option spec is often not helpful to the user who entered the command, and I've found I need to take steps to address this. A package like Perl's Getopt::Long tends to a bit more mature in some of these details.

--Jon

On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu wrote:
> On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote:
>> On Thu, 2016-05-12 at 18:25 +0000, Jesse Phillips via Digitalmars-d
>> wrote:
>> […]
>>> unknown flags harder and displaying help challenging. So I'd like
>>> to see getopt merge with another getopt
>>
>> getopt is a 1970s C solution to the problem of command line parsing.
>> Most programming languages have moved on from getopt and created
>> language-idiomatic solutions to the problem. Indeed there are other,
>> better solution in C now as well.
>
> What are those and how are they better? -- Andrei

I wrote what I think is an idiomatic-D command line argument parser:

    https://github.com/jasonwhite/darg

You basically define a struct with your options as members. The help string is then created at compile time(!). I find this much cleaner than std.getopt and the usage/help is prettier.

On 5/14/16 10:29 AM, Russel Winder via Digitalmars-d wrote:
> On Sat, 2016-05-14 at 16:17 +0300, Andrei Alexandrescu via Digitalmars-
> d wrote:
> […]
>
>> I showed a fellow programmer std.getopt. We were both on laptops. He
>> wanted to show me how good Python's argparse is and how D should
>> copy
>> it. By the end of the chat it was obvious argparse was much more
>> verbose
>> and less pleasant to use than getopt. Like you have to create an
>> object
>> (?!?!) to parse the command line and many other lines of nonsense.
>
> "verbose", "less pleasant" and "nonsense" are hardly the right terms
> unless the intention is to try to convince us using advocacy research.

Now that I've read your "getopt is a 1970s C solution..." comment I realize this might be a simple misunderstanding related to the fact you've never looked at D's std.getopt. It has nothing to do with C's getopt. The closest ancestor is Perl's http://perldoc.perl.org/Getopt/Long.html, but in D it's a lot better because of strong typing. Pray please take a look and sorry for taking your confusion for a semantic grenade. -- Andrei