Python's simplicity philosophy

[BW Glitch]

Douglas Alan wrote:

> "Dave Brueck" <dave at pythonapocrypha.com> writes:
> 
> 
>>>Of course I am not joking.  I see no good coming from the mantra, when
>>>the mantra should be instead what I said it should be:
> 
> 
>>>"small, clean, simple, powerful, general, elegant"
> 
> 
>>It's really a matter of taste - both "versions" mean about the same to me
>>(and to me both mean "get rid of reduce()" ;-) ).
> 
> 
> No, my mantra plainly states to keep general and powerful features
> over specific, tailored features.  reduce() is more general and
> powerful than sum(), and would thus clearly be preferred by my
> mantra.
> 
> The mantra "there should be only one obvious way to do it" apparently
> implies that one should remove powerful, general features like
> reduce() from the language, and clutter it up instead with lots of
> specific, tailored features like overloaded sum() and max().  

That's not what _I_ understand. There's room for powerful features, but 
when these features gives trouble to the people who just want something 
done, then another approach should be taken.

And I'm not talking about stupid people. I'm talking about the 
microbiolgist/chemist/physics/etc who is programming because of need. CS 
people would do a better job, but they are more costly to bring up in 
any proyect that requires especific knowledge in one area.

> If so,
> clearly this mantra is harmful, and will ultimately result in Python
> becoming a bloated language filled up with "one obvious way" to solve
> every particular idiom.  This would be very bad, and make it less like
> Python and more like Perl.
> 

You feel ok? Perl's mantra is "More Than One Way To Do It"...

> I can already see what's going to happen with sum(): Ultimately,
> people will realize that they may want to perform more general types
> of sums, using alternate addition operations.  (For intance, there may
> be a number of different ways that you might add together vectors --
> e.g, city block geometry vs. normal geometry.  Or you may want to add
> together numbers using modular arithmetic, without worrying about
> overflowing into bignums.)  So, a new feature will be added to sum()
> to allow an alternate summing function to be passed into sum().  Then
> reduce() will have effectively been put back into the language, only
> its name will have been changed, and its interface will have been
> changed so that everyone who has taken CS-101 and knows off the top of
> their head what reduce() is and does, won't easily be able to find it.
> 

I don't get you. There's a reason why special functions can be 
overloaded (__init__, __cmp__, etc.; I don't use others very often). 
That would allow for this kind of special treatments. Besides GvR would 
not accept your scenario.

Also, whytf do you mention so much CS101? Maybe you took the course with 
LISP, assembly and Scheme, but AFAIK, not everyone has/had access to 
this course. Many people learned to program way before taking CS101. 
IMHO, you think that the only people that should make software is a CS 
major.

> Yes, there are other parts of The Zen of Python that point to the
> powerful and general, rather than the clutter of specific and
> tailored, but nobody seems to quote them these days, and they surely
> are ignoring them when they want to bloat up the language with
> unneccessary features like overloaded sum() and max() functions,
> rather than to rely on trusty, powerful, and elegant reduce(), which
> can easily and lightweightedly do everything that overloaded sum() and
> max() can do and quite a bit more.

GvR (or BDFL, as most people know him) has been very careful with his 
design decisions. I've been only for about 2 years 'round here, but I've 
seen why list compressions came by, why there's no ternary operator and 
why Python uses indentation as block separations. These are design 
decisions that GvR took.

And there's a good reason why they _are_ design decisions. (Try to guess 
why. :P)

> 
> 
>>>To me, there is never *one* obviously "right way" to do anything
> 
> 
>>Never? I doubt this very much. When you want to add two numbers in a
>>programming language, what's your first impulse? Most likely it is
>>to write "a + b".
> 
> 
> Or b + a.  Perhaps we should prevent that, since that makes two
> obviously right ways to do it!
> 

Even without any algebra, any kid can tell you that 1 + 2 is the same as 
2 + 1. Replace 1 and 2 by a and b and you get the same result.

[snip]
>>And that is why I wouldn't be sad if reduce() were to disappear - I don't
>>use reduce() and _anytime_ I see reduce() in someone's code I have to slow
>>way down and sort of rehearse in my mind what it's supposed to do and see if
>>I can successfully interpret its meaning (and, when nobody's looking, I
>>might even replace it with a for-loop!).
> 
> 
> C'mon -- all reduce() is is a generalized sum or product.  What's
> there to think about?  It's as intuitive as can be.  And taught in
> every CS curiculum.  What more does one want out of a function?
> 
> |>oug

It wasn't obvious for me until later. reduce() is more likely to be used 
for optimization. IIRC, some said that optimization is the root of all evil.

Just because it's _obvious_ to you, it doesn't mean it's obvious to 
people who self taught programming.

-- 
Andres Rosado

-----BEGIN TF FAN CODE BLOCK-----
G+++ G1 G2+ BW++++ MW++ BM+ Rid+ Arm-- FR+ FW-
#3 D+ ADA N++ W OQP MUSH- BC- CN++ OM P75
-----END TF FAN CODE BLOCK-----

"Well, That's Just Prime"
"Shut up, Rattrap."
         -- Rattrap and Optimus Primal, innumerable occasions