std.getopt suggestion

[Jacob Carlborg]

On 2011-10-04 13:21, Regan Heath wrote:
> 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.
>

Exactly, yet another reason why std.getopt is badly designed.

-- 
/Jacob Carlborg