ANN: PyStream - a C++ stream emulation

[Grant Griffin]

Alex Martelli wrote:
> 
> "Grant Griffin" <g2 at seebelow.org> wrote in message
> news:39A2EF6E.D21B7E35 at seebelow.org...
>     [snip]
> > Given that 1.6 and 2.0 are virtually 100.0% backward compatible, how do
> > these new constructs actually hurt anybody?  If anything, aren't the
> 
> Adding features 'hurts' by bloating a program/language/library/whatever.
> 
> Making it larger, richer, more complicated: that is damage in itself.
> 
> Complexity does not grow linearly in the number of features, but rather
> sort of exponentially, since each feature 'interacts' with some fraction
> of other features.  The natural trend is always towards more and more
> features (just as, in general, it's towards growth of entropy...), which
> is why one develops a counter-attitude, prizing *simplicity*.  Each 'new
> feature' must be seen to AMPLY 'pay for itself' before overcoming this
> healthy resistance.
> 
> Or, to put it more poetically...:
> 
> "You know you've achieved perfection in design, not when you have nothing
> more to add, but when you have nothing more to take away." (Antoine de
> Saint-Exupery).

Those are good points, and I agree with the quote--particular in the
case of Python, which it seems almost written to characterize.

I guess the usual motivation for the "creeping feature creature" (CFC)
is the instinct for "growth".  Growth, in terms of language design,
means adding new constructs: without new constructs, a language might be
seen by some as suffering some form of "death".  But Perl is a sort of
counter-example here; clearly it does't need more constructs <wink>, so
the new Perl 6 seems directed mainly at "growth" in less usual, less
tangible terms, e.g., better source code <subliminal: just throw the
baby out with the bathwater>.

C is a good example of something that seems to have withstood the CFC
fairly well; K&R C was fine for many years, slowly leading to ANSI C,
which added a few (but very useful) features; then C++ (a.k.a. "C3K"
<wink>) came along to support object-oriented programming with a large
new set of features (which, again, are very useful--oh, except for
"public", "private", "protected", and "friend" <subliminal: coined by
mr. rogers>.)

Python is so beautifully and simply designed ("beautiful is better than
ugly", "simple is better than complex"), that it's hard to want to add
anything to it.  Even so, I'm glad to see it being augmented by
assigning augmented assignment operators to it; this seems to sacrifice
a small amount of simplicity in terms of number of constructs to gain
some significant simplicity in terms of source code.  It also improves
the beauty <subliminal: in the beholder> of both the language and the
source code.

However, when I read some of the slides from Guido's recent talk, I
wondered if our beloved BDFL might be going in the wrong direction by
adding some very complicated new list constructs (because complicated
isn't better than complex).

Nothwistanding the (fair) point made elsewhere in this thread to the
effect that everybody has their pet feature, I think I could defend
augmentation operators as something very simple for almost anyone to
understand; this is in contrast to the list operators in Guido's slides;
frankly, those blew right over me <subliminal: not bright but makes up
for it in laziness>.

So, a design principle I might suggest for Python would be "keep all
constructs so simple even g2 can understand it".  ("lambda" already
pushs that envelope <wink>.)  To put that in more concrete terms, I hope
Python never loses its status as a sort of "executable pseudo
code"--something which an experienced programmer with no advance
knowledge of the language can more-or-less understand.

your-benevolent-dictator-for-post-<wink>-ly y'rs,

=g2
-- 
_____________________________________________________________________

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