UserLinux chooses Python as "interpretive language" of choice

[John Roth]

"Skip Montanaro" <skip at pobox.com> wrote in message
news:mailman.364.1071886706.9307.python-list at python.org...
>
>     John> The biggest problem is that I think Python is beginning to
sucumb
>     John> to the "we're better so we don't have to try harder" syndrome.
One
>     John> of these days, someone is going to start chewing up the user
base,
>     John> and for a while it looked like Ruby might have been it.
>
> Can you give some concrete examples which support your contention?

I think the discussion on this thread is a reasonably good example [grin].

The responses to my comment about method calls with no
arguements should say everything that needs to be said about
attitude.

Let's skip the fluf and get to the crux. There are four languages (not
counting
minor entries) in the space Python occupies. In alphabetical order, they
are:
Perl, Python, Ruby and TCL. The originators of those languages have very
different language design philosophies.

Larry Wall (Perl): There's more than one way to do it.

Guido vanRossum (Python): There should only be one obvious way to
do anything significant.

Metz (Ruby): I want a language that's both productive and fun to program.

John Osterhout (TCL). I want a language I can embed in tools as a common
scripting language.

Notice that there is only one polarity here: Perl vs Python. Ruby goes
meta on the discussion in that it looks at what the customer (the developer)
*wants*, rather than what the language designer thinks they should have.

And *that* is the crux here. A fairly large number of people I respect
have used Python and have migrated to Ruby. For a long time, the basic
flow was from Perl to Python, for reasons that we don't need to hash over
again.

Most businesses would look at a competitor who is stealing customers
as an opportunity to figure out what those customers want that they
aren't getting.

The jihad against the "functional" builtins is a good case in point.
The replacements for apply, map and filter seem to be adequate,
and in the case of list comprehensions, pretty darned useful although
I think that it's a rather baroque addition to an otherwise very clear
and comprehensible language.

On the other hand, claiming that sum() is an adequate replacement
for reduce() is so silly that it borders on the absurd. The only
explanation I can come up with for that level of absurdity is
a desire to get rid of a feature, regardless of what it looks like.
In other words, a jihad (holy war.)

There is no replacement for lambda in sight, even though lambda is
arguably the ***largest single*** one of the functional constructs
that needs work, and has obviously needed work for a long time.

The obvious replacement for lambda, which is some form of
inline block, has not been seriously discussed, with proposed
syntax and examples, anywhere I've seen it. Clearly, I'm
not ominiscient, so that doesn't mean it hasn't, though.

The PEP 308 mess has left a rather sour taste in a lot of
people's mouths: there was a clear majority in favor of
doing *something*, but the voting was rigged (although I
doubt if it was done deliberately) to make certain that
no single proposal would get a majority.

>
> Skip
>