UserLinux chooses Python as "interpretive language" of choice
skip at pobox.com
Sat Dec 20 17:10:33 CET 2003
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.
John> One of these days, someone is going to start chewing up the user
John> base, and for a while it looked like Ruby might have been it.
>> Can you give some concrete examples which support your contention?
John> I think the discussion on this thread is a reasonably good example
John> The responses to my comment about method calls with no arguements
John> should say everything that needs to be said about attitude.
Not really. You're holding this discussion on comp.lang.python, not on
python-dev at python.org. I interpreted your statement about not having to
"try harder" as being aimed at the people who work on the language and the
standard library. Perhaps I was mistaken. In any case, I don't see it as
necessarily a bad thing that there are multiple languages out there with
overlapping features and audiences. They absorb some ideas but not others,
and when they do they don't absorb them in precisely the same way. You can
interpret that as not trying harder, but I don't.
Python's design doesn't admit the option of calling functions without the
parens. Perl's and Ruby's do. On the other hand, functions are first-class
objects in Python. I don't know about Ruby, but in Perl, whether or not a
function is called or treated as a piece of data is very context-dependent,
to the point of near madness for people like myself who don't use it day in
and day out.
John> Let's skip the fluf and get to the crux. There are four languages
John> (not counting minor entries) in the space Python occupies.
John> Larry Wall (Perl): There's more than one way to do it.
John> Guido vanRossum (Python): There should only be one obvious way to
John> do anything significant.
John> Metz (Ruby): I want a language that's both productive and fun to
John> John Osterhout (TCL). I want a language I can embed in tools as a
John> common scripting language.
John> Notice that there is only one polarity here: Perl vs Python. Ruby
John> goes meta on the discussion in that it looks at what the customer
John> (the developer) *wants*, rather than what the language designer
John> thinks they should have.
Different design philosophies result in different languages. That's to be
expected. If Ruby floats your boat, use it. Advocate for it if you like,
but don't expect that because you like Ruby's philosophy better that Python
necessarily ought to move in that direction. I happen to think Python is
both productive and fun to use. But that's just me.
John> Most businesses would look at a competitor who is stealing
John> customers as an opportunity to figure out what those customers
John> want that they aren't getting.
Who's stealing customers? This is open source. We have no shareholders or
board of directors to appease. We scratch our own itches. If Ruby relieves
itching for more people than Python, so be it. Nobody's going to go out of
business because of it.
John> The jihad against the "functional" builtins is a good case in
John> point. The replacements for apply, map and filter seem to be
John> adequate, and in the case of list comprehensions, pretty darned
John> useful although I think that it's a rather baroque addition to an
John> otherwise very clear and comprehensible language.
Why do you call it a "jihad"? Guido has stated on multiple occasions that
he regretted adding functional constructs to the language. I still can't
get to the Python website (have to wait another two hours for my ISP to
reload its tables), but here's a Google pointer to an HTML-ized version of
his OSCON 2002 Powerpoint slides:
John> On the other hand, claiming that sum() is an adequate replacement
John> for reduce() is so silly that it borders on the absurd.
No, operationally that's a correct statement. People have looked at the use
of reduce() in a number of different contexts. In all but the rarest of
cases, reduce() was used to sum a list of numbers. sum() is a perfectly
adequate replacement in all but those rare cases and is easier to read as
well. As Guido mentioned in the talk I referenced above:
nobody uses it, few understand it
a for loop is clearer & (usually) faster
John> The only explanation I can come up with for that level of
John> absurdity is a desire to get rid of a feature, regardless of what
John> it looks like. In other words, a jihad (holy war.)
No, it's simply not used very much. Python never has been a very strong
functional language. It's always been a very strong object-oriented
language. Use it the way it's strongest.
John> There is no replacement for lambda in sight, even though lambda is
John> arguably the ***largest single*** one of the functional constructs
John> that needs work, and has obviously needed work for a long time.
Once again, you desire Python to be something it is not. If you want a
strong functional language, program in Lisp or Haskell.
John> The obvious replacement for lambda, which is some form of inline
John> block, has not been seriously discussed, with proposed syntax and
John> examples, anywhere I've seen it. Clearly, I'm not ominiscient, so
John> that doesn't mean it hasn't, though.
Anonymous blocks are not a replacement for lambdas, named functions are.
How do you pass parameters to an anonymous block?
John> The PEP 308 mess has left a rather sour taste in a lot of people's
John> mouths: there was a clear majority in favor of doing *something*,
John> but the voting was rigged (although I doubt if it was done
John> deliberately) to make certain that no single proposal would get a
Again, it's something that doesn't fit easily into Python's design. There
were several ternary operator proposals advanced, but none was a clear
winner. Guido's a conservative language designer for the most part. It's
better to leave it out than to put something in you'll regret later. PEP
308 wasn't the first time the ternary operator discussion has come up, by
the way. Functional programming, ternary operators, anonymous code blocks.
They've all been issues for a long time.
You seem to have a burr under your saddle about this stuff. I'm not sure
why. Maybe it's time to get out the curry comb...
More information about the Python-list