reduce() anomaly?

[Alex Martelli]

Re: reduce()--what is it good for? (was: Re: reduce() anomaly?)

David Eppstein wrote:
...[color=blue][color=green]
>> Wen seq is any iterable, all you need is izip(seq, islice(seq, 1, None)),
>> and you'll be creating no new list whatsoever. Still, tradeoffs in
>> obscurity (and performance for midsized lists) are quite as clear.[/color]
>
> If I'm not mistaken, this is buggy when seq is an iterable, and you need[/color]

Sorry, I should have said something like "re-iterable" -- an object such
that e.g.:
it1 = iter(seq)
val1 = it1.next()
it2 = iter(seq)
val2 = it2.next()
assert val1 == val2
holds (and keeps holding as you keen next'ing:-). list, tuple, dict, etc.
In particular, when the idiom zip(seq, seq[1:]) works, so should this one
(note in passing that, in said idiom, there is no need to slice the first
seq in the zip call to seq[:-1] -- zip truncates at the end of the
_shorter_ sequence anyway).
[color=blue]
> to do something like
> seq1,seq2 = tee(seq)
> izip(seq1,islic e(seq2,1,None))
> instead.[/color]

Yes, this is totally general. However, even though tee has now (2.4)
been implemented very smartly, this overall approach is still way
"conceptual ly heavy" (IMHO) when compared to, e.g.:

def window_by_2(it) :
it = iter(it)
first = it.next()
for second in it:
yield first, second
fist = second

in any case, I do think that such 'windowing' is a general enough
need that it deserves its own optimized itertool...


Alex

[Christopher A. Craig]

Re: Python's simplicity philosophy

pmaupin@speakea sy.net (Patrick Maupin) writes:
[color=blue]
> Douglas Alan wrote:[color=green]
> > Then your children were done a great diservice by receiving a poor
> > education. (Assuming that is that they wanted to learn Computer
> > Science, and not Programming in Pascal or Programming in C.)[/color]
>
> I'm sorry, but from a pure CS viewpoint, reduce() is way off the
> radar screen. Especially for a 101 course. If either of my daughters
> wanted to discuss reduce() while taking such a course, I'd want to
> see the curriculum to figure out what they _weren't_ being taught.[/color]

I'd tend to agree, and I've never found myself on the not teaching
generalities side of this debate before. An intro CS class should be
about intro to Computer Science and not any particular language, but
reduce() is a fairly specific functional programming concept. To say
that it should be taught in an intro class is like saying you should
deal with metaclasses, function pointers, or the stack pointer
immediately to teach good computer science. Algorithms, data
structures, state machines and computational theory are fairly basic
computer science, functional programming can be used to present those,
but is by no means needed.

Also the assumption isn't that Python users are stupid, it's that they
may have little to no CS training. Python wasn't designed for the
exclusive use of CS trained individuals (which is a good thing,
because I use it to teach computers to Boy Scouts).

Back on topic, I very rarely use reduce() in Python and then only for
optimization (which I rarely do). The vast majority of the time I
just use a for loop; it just seems to flow better.

--
Christopher A. Craig <list-python@ccraig.o rg>
"Tragedy is when I cut my finger. Comedy is when you fall in an open
sewer and die." Mel Brooks.

[eichin@metacarta.com]

Re: Python's simplicity philosophy

re cs 101: I'm told (by friends who were undergrads there in the early
90's) that Yale used to have an intro to CS course taught by the late
Alan Perlis. The usual high level concepts you'd expect - but since
it helps a lot to have a language to give examples in, it used APL.

APL has the kind of array manipulation tools that these days you find
in matlab or other specialized tools - I'd say "that other languages
aspire to" but from the looks of it other languages *don't* aspire to
that kind of array handling. But the point here is that "reduce" is
fundamental: x/i5 (where x is multiplication-sign and i is iota) is
a lot like reduce(int.__mu l__, range(1,6)), it's just "readable" if
you're comfortable with the notation (and more general, I can't find
a builtin way to say "coerced multiply" without lambda, in 30 seconds
of poking around.) On the other hand, that readability does assume
you're thinking in terms of throwing arrays around, which can be
an... *odd* way of looking at things, though of course when it fits,
it's very nice.

In other words, I'd expect anyone who had a reasonably rich CS
background to have been exposed to it, either from the historical
perspective, the "languages influence how you think" perspective, or
the mathematical operation perspective.

At the same time, I'll admit to not having used it (I've only been
using python for a year, and will more likely write an
accumulator-style block since it will always be clearer than a lambda
(which is what you generally need for reduce - if you are going to
write a function anyway, it's easier to just write an n-adic instead
of only dyadic function, and skip the need for reduce altogether - and
python has a "bias for functions", the gap between "sum" and "write a
function for the whole thing" is fairly narrow.)

(Hmm, r5rs doesn't have reduce, but mit-scheme does.)

[eichin@metacarta.com]

Re: Python's simplicity philosophy

> you're comfortable with the notation (and more general, I can't find[color=blue]
> a builtin way to say "coerced multiply" without lambda, in 30 seconds
> of poking around.) ...[/color]

Sigh, I just realized - everyone talking about operator.mul was being
*literal*, not abstract, there's actually an operator package :-) Oops.
Not that reduce(operator .mul, range(1,6)) is any more readable, I'd
still define Product around it...

[Michael T. Babcock]

Re: Python's simplicity philosophy

On Wed, Nov 12, 2003 at 08:28:29AM +0000, Robin Becker wrote:[color=blue]
> sequence.sum()
> sequence.reduce (operator.add[,init])
> sequence.filter (func) etc etc
>
> That would make these frighteningly incomprehensibl e ;)
> concepts seem less like functional programming. Personally I wouldn't
> like that to happen.[/color]

I'm hoping you were being sarcastic ... but I get the feeling you aren't.

Why, pray-tell, would you want an OO program to do:

results = [ func(x) for x in sequence ]

... instead of ...

results = sequence.map(fu nc) ??

I can understand if you're writing highly LISP-like Python (see IBM's
articles on functional programming with Python for example). However, I
don't see the 'harm' in offering functional methods to lists/arrays.

Looking at this code I wrote today:

matches = [ get_matches(fil e) for file in duplicates ]
todelete = [ get_oldest(file s) for files in matches ]

... would end up being ...

matches = duplicates.map( get_matches)
todelete = matches.map(get _oldest)

... or better ...

todelete = duplicates.map( get_matches).ma p(get_oldest)

... and I somewhat like that as I look at it.
--
Michael T. Babcock
CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc)

http://www.fibrespeed.net/~mbabcock/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: http://www.fibrespeed.net/~mbabcock/

iQF1AwUBP7JnS2/Ol25qCQydAQIpSA sAkWwusLupCYm59 p2+0Ms6cSfJpdmM CgZB
U6J/0UJgeV6MKdRPVMD E8D3Lbvi5fOldQI HAeRhwbUOJsZYCN P2VHkVEZzuV/2e2
1JDF8FEiIBr7eWN Xwy6lS77A/JZ4223e44rFToS3 dIkh4Zq0UJPWRzv 1rhTsaXp5
F9/qxPzhsAwg7i0Wsa r+7aUTUQtQMGdl1 eYKnKY/nEMnYN5YaKLnrfu XJuC7/vd0
w51tfuvIjZwNjZU tDmx6kFVpBFJOlM 2NcDELA/xHAFfzqJ5KVRTGh av7Mi2TQ7D5
JFeU9dpD7F11gZw/z91z/aVtOMpOC5+3OGku XwFx393Sn42ZziF ct9Bans5SdeyP
HClMFsNdonGpeaG 7nxSBrvI4sNnwJ2/1u4pMni2YxkqhvU eexBPoWhSEGZexu bum
yFg8Bi/CgjlaoiGTNxSyil b8IZ0Jr+w0qHgZk Bf+uVRcgISypH7p 1Q==
=z+Uz
-----END PGP SIGNATURE-----

[Dave Brueck]

Re: Python's simplicity philosophy

> > On Wed, Nov 12, 2003 at 08:28:29AM +0000, Robin Becker wrote:[color=blue][color=green][color=darkred]
> > > sequence.sum()
> > > sequence.reduce (operator.add[,init])
> > > sequence.filter (func) etc etc
> > >
> > > That would make these frighteningly incomprehensibl e ;)
> > > concepts seem less like functional programming. Personally I wouldn't
> > > like that to happen.[/color]
> >
> > I'm hoping you were being sarcastic ... but I get the feeling you aren't.
> >
> > Why, pray-tell, would you want an OO program to do:
> >
> > results = [ func(x) for x in sequence ]
> >
> > ... instead of ...
> >
> > results = sequence.map(fu nc) ??[/color][/color]

My apologies: my goofy mailer isn't adding the "On <date>, <person> wrote:"
lines, so it sort of confuses what Robin wrote with what Michael wrote. Sorry!

-Dave

[Dave Brueck]

Re: Python's simplicity philosophy

> On Wed, Nov 12, 2003 at 08:28:29AM +0000, Robin Becker wrote:[color=blue][color=green]
> > sequence.sum()
> > sequence.reduce (operator.add[,init])
> > sequence.filter (func) etc etc
> >
> > That would make these frighteningly incomprehensibl e ;)
> > concepts seem less like functional programming. Personally I wouldn't
> > like that to happen.[/color]
>
> I'm hoping you were being sarcastic ... but I get the feeling you aren't.
>
> Why, pray-tell, would you want an OO program to do:
>
> results = [ func(x) for x in sequence ]
>
> ... instead of ...
>
> results = sequence.map(fu nc) ??[/color]

Because I find the first much more readable (and IMO the "an OO program to
do" bit is irrelevent from a practical point of view).

Also, someone not familiar with either version is likely to correctly guess
what the first one does. It's not an issue of whether or not a person can be
taught what 'map' means). It's subjective, yes, but not _completely_
subjective because the "guessabili ty" of the first form is higher because it
uses other well-known keywords to do its thing. (FWIW I don't think map() is
that big of a deal, but you asked... :) ).

-Dave

[Douglas Alan]

Re: Python's simplicity philosophy

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue]
> Douglas Alan:[/color]
[color=blue][color=green]
>> Then you weren't taught Computer Science -- you were taught Fortran
>> programming. Computer Science teaches general concepts, not specific
>> languages.[/color][/color]
[color=blue]
> I agree with Alex on this. I got a BS in CS but didn't learn about
> lambda, reduce, map, and other aspects of functional programming
> until years later, and it still took some effort to understand it.
> (Granted, learning on my own at that point.)[/color]
[color=blue]
> But I well knew what 'sum' did.[/color]

How's that? I've never used a programming language that has sum() in
it. (Or at least not that I was aware of.) In fact, the *Python* I
use doesn't even have sum() in it! I've used a number of languages
that have reduce(). If I didn't already know that it exists, I
wouldn't even think to look in the manual for a function that adds up
a sequence of numbers, since such a function is so uncommon and
special-purpose.

(Someone pointed out that different versions of Scheme vary on whether
they give you reduce. In Scheme reduce would have fewer uses since
Scheme uses prefix notation, and operators like "+" can already take
any number of arguments (this is a definite advantage to prefix
notation). Therefore, in Scheme, to add up all of the numbers in a
list, you can just use apply and '+', like so: "(apply + my-list)".)
[color=blue]
> Was I not taught Computer Science?[/color]

I would say that if you didn't get introduced to at least the concept
of functional programming and a hint of how it works, then something
was seriously wrong with your CS education.
[color=blue][color=green]
>> But if you end up going and removing elegant features understood by
>> anyone who has studied Computer Science because you think your
>> audience is too dumb to make a slight leap from the specific to the
>> general that can be explained on one simple sentence, then you are
>> making those trade-off decisions in the *utterly* wrong manner.
>> You should be assuming that your audience are the smart people that
>> they are, rather than the idiots you are assuming them to be.[/color][/color]
[color=blue]
> Your predicate (that it's understood by anyone who has studied
> CS) is false so your argument is moot.[/color]

It's irrelevant whether or not many people have received poor CS
educations -- there are many people who haven't. These people should
be pleased to find reduce() in Python. And the people who received
poor or no CS educations can learn reduce() in under a minute and
should be happy to have been introduced to a cool and useful concept!

|>oug

[Andrew Dalke]

Re: Python's simplicity philosophy

Me:[color=blue][color=green]
> > But I well knew what 'sum' did.[/color][/color]

Douglas Alan[color=blue]
> How's that? I've never used a programming language that has sum() in
> it.[/color]

1) From Microsoft Multiplan (a pre-Excel spreadsheet). That
was one of its functions, which I used to help my Mom manage
her cheese co-op accounts in ... 1985?

2) I wrote such a routine many times for my own projects
By 1987 I was using a BASIC version (QuickBasic) which
had functions and using Pascal. But I don't recall in either of
those languages ever passing functions into an object until I
started using non-trivial C a couple of years later. (Probably
for a numerical analysis class.)
[color=blue]
> I wouldn't even think to look in the manual for a function that adds up
> a sequence of numbers, since such a function is so uncommon and
> special-purpose.[/color]

Uncommon? Here's two pre-CS 101 assignments that use
exactly that idea:
- make a computerized grade book (A=4.0, B=3.0, etc.) which
can give the grade point average
- make a program to compute the current balance of a bank
account given the initial amount and

That's not to say that the BASIC I used at that time had support
for functions. It's only to say that the functionALITY is common
and more easily understood than reduce.
[color=blue][color=green]
> > Was I not taught Computer Science?[/color]
>
> I would say that if you didn't get introduced to at least the concept
> of functional programming and a hint of how it works, then something
> was seriously wrong with your CS education.[/color]

It may be. That was my third-place major, which I did mostly
for fun. I focused more on my math and physics degrees, so might
have skipped a few things I would have learned had I been more
rigorous in my studies.

It may also be that my department focused on other things. Eg,
we had a very solid "foundation s of computer science" course
compared to some CS departments, and we learned some fuzzy
logic and expert systems because those were a focus of the
department.
[color=blue]
> It's irrelevant whether or not many people have received poor CS
> educations -- there are many people who haven't. These people should
> be pleased to find reduce() in Python. And the people who received
> poor or no CS educations can learn reduce() in under a minute and
> should be happy to have been introduced to a cool and useful concept![/color]

Actually, your claim is 'anyone can be explained reduce() in 10 seconds' ;)

I tell you this. Your estimate is completely off-base. Reduce is
more difficult to understand than sum. It requires knowing that
functions can be passed around. That is non-trivial to most,
based on my experience in explaining it to other people (which
for the most part have been computational physicists, chemists,
and biologists).

It may be different with the people you hang around -- your
email address says 'mit.edu' which is one of the *few* places
in the world which teach Scheme as the intro language for
undergrads, so you already have a strong sampling bias.

(I acknowledge my own sampling bias from observing people
in computational sciences. I hazard to guess that I know more
of those people than you do people who have studied
computer science.)

Andrew
dalke@dalkescie ntific.com

[Douglas Alan]

Re: Python's simplicity philosophy

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue]
> Me:[/color]
[color=blue][color=green][color=darkred]
>> > But I well knew what 'sum' did.[/color][/color][/color]
[color=blue]
> Douglas Alan[color=green]
>> How's that? I've never used a programming language that has sum() in
>> it.[/color][/color]
[color=blue]
> 1) From Microsoft Multiplan (a pre-Excel spreadsheet). That
> was one of its functions, which I used to help my Mom manage
> her cheese co-op accounts in ... 1985?[/color]

Okay, well I can certainly see that a spreadsheet program should have
a built-in sum() function, since that's about 50% of what spreadsheets
do! But general-purpose programming languages rarely have it.
[color=blue][color=green]
>> I wouldn't even think to look in the manual for a function that adds up
>> a sequence of numbers, since such a function is so uncommon and
>> special-purpose.[/color][/color]
[color=blue]
> Uncommon? Here's two pre-CS 101 assignments that use
> exactly that idea:
> - make a computerized grade book (A=4.0, B=3.0, etc.) which
> can give the grade point average
> - make a program to compute the current balance of a bank
> account given the initial amount and[/color]

I'm not saying that it's uncommon to want to sum a sequence of numbers
(though it's not all that common, either, for most typical programming
tasks) -- just that it's uncommon to build into the language a special
function to do it. reduce(+, seq) apply(+, seq) are much more common,
since reduce and/or apply can do the job fine and are more general.
Or just a good old-fashioned loop.
[color=blue][color=green]
>> It's irrelevant whether or not many people have received poor CS
>> educations -- there are many people who haven't. These people should
>> be pleased to find reduce() in Python. And the people who received
>> poor or no CS educations can learn reduce() in under a minute and
>> should be happy to have been introduced to a cool and useful concept![/color][/color]
[color=blue]
> Actually, your claim is 'anyone can be explained reduce() in 10 seconds' ;)[/color]

Now you want consistency from me? Boy, you ask a lot!

Besides, 10 seconds is under a minute, is it not?

Also, I said it could be explained in 10 seconds. Perhaps it takes a
minute to learn because one would need the other 50 seconds for it to
sink in.
[color=blue]
> I tell you this. Your estimate is completely off-base. Reduce is
> more difficult to understand than sum. It requires knowing that
> functions can be passed around.[/color]

Something that anyone learning the language should learn by the time
they need a special-purpose summing function! Before then, they can
use a loop. They need the practice anyway.
[color=blue]
> That is non-trivial to most, based on my experience in explaining it
> to other people (which for the most part have been computational
> physicists, chemists, and biologists).[/color]

I find this truly hard to believe. APL was a favorite among
physicists who worked at John's Hopkins Applied Physics Laboratory
where I lived for a year when I was in high school, and you wouldn't
survive five minutes in APL without being able to grok this kind of
thing.
[color=blue]
> It may be different with the people you hang around -- your email
> address says 'mit.edu' which is one of the *few* places in the world
> which teach Scheme as the intro language for undergrads, so you
> already have a strong sampling bias.[/color]

Yeah, and using Scheme was the *right* way to teach CS-101, dangit!
But, like I said, I was taught APL in high-school in MD, and no one
seemed troubled by reduce-like things, so it was hardly just an MIT
thing. In fact, people seemed to like reduce() and friends -- people
seemed to think it was a much more fun way to program, rather than
using boring ol' loops.
[color=blue]
> (I acknowledge my own sampling bias from observing people in
> computational sciences. I hazard to guess that I know more of those
> people than you do people who have studied computer science.)[/color]

Hmm, well I work for X-ray astronomers. Perhaps I should take a
poll.

|>oug

[Patrick Maupin]

Re: Python's simplicity philosophy

Douglas Alan wrote:
[color=blue]
> Describing reduce() in 10 seconds is utterly trivial to anyone with an
> IQ above 100, whether or not they have ever used sum()[/color]

Well, yeah, but they may not need or want to learn or remember it.
And then there are the corner cases, e.g. sum([]) vs.
reduce(operator .add,[]) (which throws an exception).
[color=blue]
> If someone can't understand this quickly, then they shouldn't be
> programming![/color]

Again, it's not "can't", it's whether they need to or not.
[color=blue]
> I'm sorry, but you are incorrect. When I took CS-101, we learned
> assembly language, then were assigned to write a text editor in
> assembly language, then we learned LISP and were assigned to write
> some programs in LISP, and then we learned C, and then we were
> assigned to implement LISP in C.
>
> If you can write a !$#@!!%# LISP interpreter in C, you no doubt can
> figure out something as mind-achingly simple as reduce()![/color]

Ahh, the lisp background. I _knew_ that would come out sometime :)

Seriously, though, even in this scenario -- you don't really need
reduce() to create a LISP interpreter (as I'm sure you found
when you wrote one in C).

[color=blue][color=green]
> > Ignorance is not stupidity.[/color]
>
> Assuming that your audience cannot learn the simplest of concepts is
> assuming that they are stupid, not that they are ignorant.[/color]

As I and others have pointed out, it's not a matter of assuming they
can't learn, it's a matter of assuming they have better things to
do. Many people can write all the useful programs they will ever
need without reduce, and sum() makes the percentage of Python
users who can do this even higher. (Having said that, I never
personally argued that reduce() should be removed from the language,
but I do agree that it does not have to be part of "core" Python,
and could easily be relegated to a module.)
[color=blue]
>[color=green][color=darkred]
> >> I sure hope that Python doesn't try to emulate C. It's a terrible,
> >> horrible programming language that held back the world of software
> >> development by at least a decade.[/color][/color]
>[color=green]
> > I used to hate C. But then, when it borrowed enough good concepts
> > from Pascal and other languages, and the compilers got smart enough
> > to warn you (if you cared to see the warnings) about things like
> > "if (x = y)" I stopped using Modula-2. C held software back 10
> > years in the same manner as Microsoft did, e.g. by helping to
> > standardize things to where I can buy a $199 system from WalMart
> > which would cost over $20,000 if everybody kept writing code like
> > the pointy-headed ivory tower academics thought it ought to be written.[/color]
>
> You score no points for C by saying that it is like Microsoft. That's
> a strong damnation in my book. And you really don't know how the
> world would have turned out if a different programming language had
> been adopted rather than C for all those years. Perhaps computers
> would be more expensive today, perhaps not. On the other hand, we
> might not have quite so many buffer overflow security exploits.
> Perhaps we'd have hardware support for realtime GC, which might be
> very nice. On the other hand, perhaps people would have stuck with
> assembly language for developing OS's. That wouldn't have been so
> pretty, but I'm not sure that that would have made computers more
> expensive. Perhaps a variant of Pascal or PL/1 would have taken the
> niche that C obtained. Either of those would have been better, though
> no great shakes either.[/color]

I agree that I cannot know how the world would have turned out
without C and Microsoft; but likewise, you cannot know for sure
that computer science would be ten years farther along by now :)

(And I personally feel my alternate universe is more realistic
than yours, but then everybody should feel that way about their
own private alternate universe.)
[color=blue][color=green][color=darkred]
> >> The reason for Python's wide acceptance isn't because it is
> >> particularly well-designed compared to other programming languages[/color][/color][/color]
[color=blue][color=green][color=darkred]
> >> that had similar goals of simplicity and minimality (it also isn't
> >> poorly designed compared to any of them -- it is on par with the
> >> better ones) -- the reason for its success is that it was in the right
> >> place at the right time, it had a lightweight implementation, was
> >> well-suited to scripting, and it came with batteries included.[/color][/color]
>[color=green]
> > I'd vote this as the statement in this group most likely to start
> > a religious flamewar since the lisp threads died down.[/color]
>
> The only way it could start a religious flamewar is if there are
> people who wish to present themselves as fanboys. I have said nothing
> extreme -- just what is obvious: There are many nice computer
> programming languages -- Python is but one of them. If someone
> wishes to disagree with this, then they would have to argue that there
> are no other nice programming languages. Now that would be a flame![/color]

Well, I guess I may have read more into your original statement
than you put there. You wrote "similar goals of simplicity
and minimality", and to me, the language is pretty much a gestalt
whole, in the sense that when I read "similar goals" I was thinking
about all the features that, to me, make Python Python. These goals
actually include the lightweight implementation, the portability,
the suitability to scripting, etc. In one way or another, I feel
that these contribute to its simplicity and minimality, and on
rereading your words, I think you were probably mainly referring
to the syntax and semantics. (Even there, however, as I think Alex
has pointed out, design decisions were made which might make the
semantics less than optimal, yet contribute heavily to the small
size and portability of the language.)
[color=blue]
> I'm not sure what you are getting at. There were many nice
> programming languages before Python, but not many of them, other than
> Perl, were portable and well-suited to scripting.[/color]

I was just challenging you to defend a position which it appears
in hindsight you didn't really take :)
[color=blue]
>[color=green]
> > 3) Do you _really_ think that all the batteries were included when
> > Python first came out?[/color]
>
> It certainly was not a particularly popular language until it came
> with pretty hefty batteries. There are many other languages that
> would have been equally popular before Python started coming with
> batteries.[/color]

Here is one area where I think the genius of the design shows
through. Even _before_ the batteries were included, in a crowded
field of other languages, Python was good enough to acquire enough
mindshare to start the snowball rolling, by attracting the kind of
people who can actually build batteries.
[color=blue][color=green]
> > Do you even think that Python has more batteries _right_ _now_ than
> > Perl (via CPAN), or that some competing language couldn't or hasn't
> > already been designed which can coopt other languages' batteries?[/color]
>
> Um, the last time I checked Perl was still a lot more popular than
> Python, so once again I'm not sure what you are getting at. Regarding
> whether or not some future language might also come with batteries and
> therefore steal away Python's niche merely due to having more
> batteries: Anything is possible, but this will be an uphill battle for
> another language because once a language takes a niche, it is very
> difficult for the language to be displaced. On the other hand, a new
> language can take over a sub-niche by providing more batteries in a
> particular area. PHP would be an example of this.[/color]

We are in agreement that Perl has more batteries than Python,
and also more "marketshar e." To me, this is yet another testament
to Python's good design -- it is in fact currently on a marketshare
ramp, mostly because it attracts the kind of people who can do an
excellent job of writing the batteries.
[color=blue][color=green]
> > I can accept the premise that, for Python to enjoy the acceptance it
> > does today, Guido had to be lucky in addition to being an excellent
> > language designer. But if I were to accept the premise that
> > Python's popularity is due to sheer luck alone my only logical
> > course of action would to be to buy Guido a plane ticket to Vegas
> > and front him $10,000 worth of chips, because he has been extremely
> > lucky for many years now.[/color]
>
> I never claimed *anything* like the assertion that Python's popularity
> is due to luck alone![/color]

In the post I was responding to, you wrote "The reason for Python's wide
acceptance isn't because it is particularly well-designed compared to
other programming languages," and you also used the phrase "in the right
place at the right time." To me, these statements taken together implied
that you thought the process leading to Python's ascending popularity was
mostly stochastic.

Your later posting (and a more careful reading of your original post) help
me to put your words in the proper context, and seem to indicate that our
opinions on the subject are not as divergent as I first thought they were.

Regards,
Pat

[Douglas Alan]

Re: Python's simplicity philosophy

pmaupin@speakea sy.net (Patrick Maupin) writes:
[color=blue]
> Douglas Alan wrote:[/color]
[color=blue][color=green]
>> Describing reduce() in 10 seconds is utterly trivial to anyone with an
>> IQ above 100, whether or not they have ever used sum()[/color][/color]
[color=blue]
> Well, yeah, but they may not need or want to learn or remember it.
> And then there are the corner cases, e.g. sum([]) vs.
> reduce(operator .add,[]) (which throws an exception).[/color]
[color=blue][color=green]
>> If someone can't understand this quickly, then they shouldn't be
>> programming![/color][/color]
[color=blue]
> Again, it's not "can't", it's whether they need to or not.[/color]

If you don't want to learn a cool concept that will only take you 60
seconds to learn, then you shouldn't be programming! Or you can stick
to loops.

The argument that some programmers might be too lazy to want to learn
powerful, simple, and elegant features that can be taught in seconds,
is no good reason to remove such features from Python and bloat Python
by replacing them with a plethora of less powerful, less elegant
features.
[color=blue][color=green]
>> I'm sorry, but you are incorrect. When I took CS-101, we learned
>> assembly language, then were assigned to write a text editor in
>> assembly language, then we learned LISP and were assigned to write
>> some programs in LISP, and then we learned C, and then we were
>> assigned to implement LISP in C.[/color][/color]
[color=blue][color=green]
>> If you can write a !$#@!!%# LISP interpreter in C, you no doubt can
>> figure out something as mind-achingly simple as reduce()![/color][/color]
[color=blue]
> Ahh, the lisp background. I _knew_ that would come out sometime :)[/color]

Knowing about reduce() doesn't come from a LISP background, since it
is uncommon to use reduce() in LISP. There are few binary operators
in LISP, so instead of doing reduce(+, seq), in LISP, you would
typically do apply(+, seq). Knowing about reduce() comes from the
part of your CS education in which they give you a small taste of what
it is like to program in a purely combinator-based style. E.g., you
might have a problem set where they ask you to solve the same problem
in three different ways: (1) using iteration, (2) using recursion, (3)
using only combinators.

Besides, if you weren't exposed at all to LISP (or a LISP-like
language) while getting a CS degree, it wasn't a very good CS
program! They're going to teach you AI techniques in a different
language? That would be rather silly.
[color=blue]
> As I and others have pointed out, it's not a matter of assuming they
> can't learn, it's a matter of assuming they have better things to
> do. Many people can write all the useful programs they will ever
> need without reduce, and sum() makes the percentage of Python
> users who can do this even higher.[/color]

And as I have pointed out, it goes against the principle of simplicity
and expressiveness to remove an easy to use and easy to learn simple
and powerful feature with a slew of specific, tailored features. If
reduce() can be relegated to a library or for the user to implement
for himself, then so can sum(). If the language is to only have one,
it should be reduce().
[color=blue]
> I agree that I cannot know how the world would have turned out
> without C and Microsoft; but likewise, you cannot know for sure
> that computer science would be ten years farther along by now :)[/color]

I didn't say it held back Computer Science -- Computer Science went
along fine. I said it held back software development.

That's not to say that something else wouldn't have taken C's place in
holding back software development, but, in that case, I'd be railing
against that instead.
[color=blue]
> Here is one area where I think the genius of the design shows
> through. Even _before_ the batteries were included, in a crowded
> field of other languages, Python was good enough to acquire enough
> mindshare to start the snowball rolling, by attracting the kind of
> people who can actually build batteries.[/color]

I think that Python always came with batteries, since it was designed
to be the scripting language for an OS called Amoeba that Guido was
working on. There were precious few other well-designed,
well-implemented languages around that the time that were aimed at
being scripting languages (and didn't run only on Lisp machines or
what have you).

|>oug

[Douglas Alan]

How sum() should really be done

Douglas Alan <nessus@mit.edu > writes:
[color=blue]
> Knowing about reduce() doesn't come from a LISP background, since it
> is uncommon to use reduce() in LISP. There are few binary operators
> in LISP, so instead of doing reduce(+, seq), in LISP, you would
> typically do apply(+, seq).[/color]

Ah, that reminds me -- both sum() and reduce() can be removed from
Python by extending operator.add so that it will take any number of
arguments. Then you can add up a sequence of numbers by doing
add(*seq). The same thing goes for every other binary operator where
it makes sense to operate on more than two arguments at a time.

Now that's clean, simple, and powerful.

|>oug

[Robin Becker]

Re: Python's simplicity philosophy

In article <mailman.670.10 68656478.702.py thon-list@python.org >, Michael
T. Babcock <mbabcock@fibre speed.net> writes
.......[color=blue]
>I'm hoping you were being sarcastic ... but I get the feeling you aren't.
>
>Why, pray-tell, would you want an OO program to do:
>
>results = [ func(x) for x in sequence ]
>
>... instead of ...
>
>results = sequence.map(fu nc) ??
>[/color]
..... well actually I'm quite happy with reduce as a function or as a
method on sequences. I actually feel uncomfortable with all the plethora
of iteration tools, comprehensions etc etc. However, I'm not forced to
use them.
--
Robin Becker

[Ville Vainio]

Too much builtins (was Re: Python's simplicity philosophy

Douglas Alan <nessus@mit.edu > writes:

[reduce]
[color=blue][color=green][color=darkred]
> >> If someone can't understand this quickly, then they shouldn't be
> >> programming![/color][/color]
>[color=green]
> > Again, it's not "can't", it's whether they need to or not.[/color]
>
> If you don't want to learn a cool concept that will only take you 60
> seconds to learn, then you shouldn't be programming! Or you can stick
> to loops.[/color]

As far as reduce goes, ppl will undoubtedly take a look at the
description, understand it in well under 60 seconds, can't think of
any use for the feature during the next 60 seconds (that wouldn't be
clearer with explicit iteration), and forget it soon after turning the
page. I didn't forget it, just wondered why such an oddball feature
was a builtin. Obviously reduce can rock someone's world, but life is
too short to bother if it doesn't rock yours.
[color=blue]
> and powerful feature with a slew of specific, tailored features. If
> reduce() can be relegated to a library or for the user to implement
> for himself, then so can sum(). If the language is to only have one,
> it should be reduce().[/color]

I also think that reduce, sum, map and filter (and lots of others,
__builtins__ has *too much stuff*) should be removed from builtins,
but that will probably take some time (1997 years?). LC's and genexpes
will take care of most of that stuff. And people can always do:

from funtional import *
# map, filter, reduce, curry, ... (I want lots of these :)

There are also tons of functions that should be in sys, math or
whatever:

reload, repr, divmod, max, min, hash, id, compile, hex...

What's your pet deprecation candidate? I have always thought
`backticks` as repr has got to be the most useless feature around.

--
Ville Vainio http://www.students.tut.fi/~vainio24