On 2011-10-04 13:21, Regan Heath wrote:
On Tue, 04 Oct 2011 05:20:48 +0100, Walter Bright
<newshou...@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
