counting occurrences

[Grant Griffin]

Alex Martelli wrote:
> 
> "Tim Peters" <tim.one at home.com> wrote in message
> news:mailman.997165211.14595.python-list at python.org...
>     ...
> > Fear of that kind of bloat held up the introduction of dict.update() for
> > years:  in d.update(e), in case of duplicate keys k, most apps seem to
> want
> > e[k] to "win", but some want d[k] to triumph, others would prefer an
> > exception get raised, and still others want the new d[k] to be (d[k],
> e[k])
> > or [d[k], e[k]] or one of those swapped.  Guido was in a rare mood when he
> > said "oh, screw it -- e[k] wins".  You might be able to sell
> 
> I guess that must be part of what makes him a great language
> designer and me a poor one: faced with such a situation, where
> several slight variations make sense, MY instincts would be
> to add a second optional flag parameter -- HIS are to block
> everything for years and finally choose ONE alternative, no
> options allowed.  When looking at it "in the small", my
> instincts may make sense to most designers -- but, add half
> a dozen option-flags to each of a few hundreds analogous
> situation in a language and its libraries, and I suspect my
> option-giving instincts would have led to substantial bloat,
> while his have kept things reasonably streamlined and
> simple, without in the end substantially reducing the power
> actually made available to programmers.  Live and learn...!

I supposed language designers have to be careful that feature bloat
doesn't become "death by a thousand cuts".

Of course, Perl is the poster-child here.  But given that a thing like
Perl is _supposed_ to offer "more than one way to do it" I always wonder
how the designer knows how many multiple ways to do something are
enough.  (In other words, "more than one way to do it" isn't a unifying
design principle.)  But in that case, I guess the successful language
designers can only make some sort of trade of "value added" versus
bloat.

But conversely, any strict form of "minimalism" is likewise a fetish. 
To that end, Tim's famous philosophy wisely hedges using fuzzy words
like "should", "preferably", and "obvious"*.

But as someone who is trying to begin Unix (via Linux), I've seen the
benefit of the limitation of features that good ol' DOS commands have. 
DOS commands typically offer only a half-dozen options--only three or so
of which you regularly use.  And although one sometimes wishes a DOS
command could do something that it can't, the converse problem of having
to read, digest, understand, and master the twelve dozen options of each
Linux command is a bit daunting.  But if they would put the most
important six options at that top of the man page, that might help a
_little_...

a-forrest-with-more-trees-requires-more-obvious-path-markings-ly y'rs,

=g2

*   the-trick-to-a-good-philosophy-is-to-articulate-enough-
    contradictory-principles-so-that-what-you-really-want-
    to-do-can-always-be-rationalized<wink>-ly y'rs  - tim
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation            http://www.iowegian.com