std.getopt suggestion

Jonathan M Davis jmdavisProg at gmx.com
Mon Oct 3 21:30:39 PDT 2011


On Monday, October 03, 2011 21:20:48 Walter Bright wrote:
> On 9/29/2011 11:54 AM, Jonathan M Davis wrote:
> > And yes, that's an argument by ad populum
> > (or whatever the exact name is), but what's considered "clutter" is
> > subjective. Yes, the improvement would be relatively minor, but so's the
> > cost of the change, and while it doesn't necessarily show that you're
> > wrong when no one seems to agree with you, it does at least say
> > something when no one agrees with you.
> 
> I've been only a casual user of std.getopt, barely scratching the surface of
> what it can do. But I do have a few general thoughts on this.
> 
> One of the very hardest things in design is knowing when to say "no" to a
> new feature. The feature is desired by some subset of the users, it can be
> ignored by those who have no use for it, so it seems like an unequivocal
> win, right?
> 
> But:
> 
> 1. It adds to the "cognitive load" of the product. The cognitive load is how
> thick the manual is. The bigger it is, the more intimidating it is, and the
> fewer will dare to even open it. There is immense attraction in simple to
> understand products. std.getopt is supposed to make life easier for
> programmers - pages and pages and pages of documentation, options, complex
> examples, etc., just lead one to say "screw it, I'll roll my own" and it
> has failed.
> 
> Steve Jobs is famously successful for paring down feature sets to the bare
> minimum that works for 90% of the users, and then doing those features very
> well.
> 
> 2. Once a feature is there, it stays forever. It's very hard to judge how
> many people rely on a feature that turns out in hindsight to be baggage.
> Removing it arbitrarily will break existing code and tick off people. C++
> has a number of hare-brained features (like trigraphs) that everyone hates
> but prove impossible to remove, despite it mucking up progress with
> language.
> 
> 3. Increasing the complexity means more maintenance, cognitive load for the
> maintenance programmer, and bugs, bugs, bugs.
> 
> 4. If a user really needs a special case not supported by std.getopt, it is
> straightforward to roll his own.
> 
> 5. Supporting (well) only a reduced feature set means that apps will tend to
> have command line behavior that is more consistent and predictable, which
> is a good thing.
> 
> 
> It's why I have rather bull-headedly resisted adding feature after feature
> to D's unittest facility. The unittest feature has been a home run for D,
> and I suspect a lot of its success has been its no-brainer simplicity and
> focus on doing one thing well.

All good thoughts, but in this case, it's an argument over rearranging how 
some of the options are set (options which are probably more or less _never_ 
set and arguably should never have been configurable in the first place for 
essentially the reasons that you're giving). So, we wouldn't be looking at 
complicating anything or increasing the cognitive load in using it. All it 
would do would be to make some mutable global variables into a struct which 
would be passed in were the programmer to actually want to set them (which 
probably never happens).

- Jonathan M Davis


More information about the Digitalmars-d mailing list