std.getopt suggestion

[Regan Heath]

On Tue, 04 Oct 2011 05:20:48 +0100, Walter Bright  
<newshound2 at digitalmars.com> wrote:
> 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.

One technique for avoiding a lot of the problems with "feature creep" is  
to create new things using existing things, instead of modifying the  
existing thing.  In this way the cognitive load of the original remains  
the same, and don't increase it's complexity or add bugs.

But, this is only possible if the original thing is written in an  
"orthogonal" manner:
http://en.wikipedia.org/wiki/Orthogonality#Computer_science

Meaning, typically, that the parts of the thing need to be encapsulated,  
so that they can be re-used by the more complex thing without introducing  
any side-effects to the original thing, or uses of the original thing.

In this particular case, because these std,.getopt options are global  
variables, building something which uses them, or std.getopt will  
introduce side effects to other uses of std.getopt.  Meaning the current  
design makes it impossible to build upon in an orthogonal manner.  This is  
the 'problem' people have with it.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/