std.getopt suggestion

[Walter Bright]

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.