Fat and happy Pythonistas (was Re: Replacement for keyword 'global' good idea? ...)

[John Roth]

"Peter Hansen" <peter at engcorp.com> wrote in message 
news:C9udnRprcKxjImnfRVn-tA at powergate.ca...
> John Roth wrote:
>> It's not going to happen because the Python community is fat and happy,
>> and is not seeing the competition moving up on the outside. 
>> Characteristics
>> that make a great language one day make a mediocre one a few years
>> later, and make a has-been a few years after that.
>
> And here I thought that was the point of Python 3000.  To let the 
> community produce a much improved language while avoiding the problems 
> caused by too much change occurring while people are trying to get useful 
> things done with what the language is _now_.  The competition (and let's 
> see a description of just what that means, too) probably has the dual 
> advantage of newness and a small, hackerish community that is more than 
> happy to see rapid and radical change.  You're right -- as with the 
> stereotypical large/slow vs. small/agile company motif -- that smaller and 
> more agile will pass larger and slow "on the outside", but you're wrong if 
> you think that means the larger-slower entity should drop what it's been 
> doing so well and try to compete entirely on the smaller-faster entity's 
> own ground.

Maybe "fat and happy" wasn't the best choice of words (and maybe
Extreme Programming wasn't Kent Beck's best choice of words either.)

However. I see nothing in the existing Python 3000 PEP that does
anything other than inspire a yawn. Sure, it's a bunch of cleanup, and
some of it is definitely needed. What I don't see is the inspired leap
forward that will once again put Python in the forefront rather than
simply being one choice among many.

What I want to see in Python 3000 is an AST based language
that lets the editors do the pretty printing. Do you want automatic
indenting or would you prefer end statements? It's an editor formatting
option. The AST neither knows or cares. Don't want to see self?
Editor formatting option. The AST knows what scope each
identifier belongs to because it's right there in the text. No need
for rules that you have to learn, sometimes the hard way.

Want to see type inference? I haven't a clue how to do it in a
dynamic language like Python, but an AST based language is a
perfect test bed for experimentation.

What's good about other languages? I see very little here
that is an examination of what Smalltalk, Ruby, Perl, etc.
seem to have gotten right and could be moved into Python
to good effect.

Talk to people who've moved from Python to Ruby, or to
some other language. Ask them why, if Python is so great,
what's even greater in that other language. If you still don't
understand, you might want to read this:

http://martinfowler.com/bliki/CollectionClosureMethod.html

Look at Pep 8. It's a compendium of coding standards
for the standard library. So far, ok. Coding standards
are generally good. But why does Guido like underscores
in method names? I know there was (and the accent is
on the word was) some research, refuted well over a decade
ago, that mixedCase was hard to read. The fact is that
_all_ conventions for separating words are hard to read
until the brain grows new synapses that handle it. Of the
options, no separation is the hardest to handle. There are
reasons why ancient texts, which had neither word
separators nor punctuation, have very contentious translations.

I find the notion that there should be one obviously right way
to do something to be a good design principle, so why isn't
there a single supported GUI library? If I'm over in Java-land,
just about everything comes with a GUI. Python ships with a
lot of little demonstration and utility scripts - none of which has
a GUI.

Part of the tone here is because of the PEP 208 voting
process. From day one, I knew it was going to fail.
Anyone who stood back and looked at the process, rather
than getting into the detail, knew it was going to fail. There
was no way that the Python community was going to come
up with a simple majority in favor of one proposal. None.
And it was obvious from the start.

And the sad fact is that a proposition of the form: "We
want a conditional expression; Guido should pick the
syntax he finds the least obnoxious and get on with it"
would have passed. Overwhelmingly.

I came across a better voting process (Condorcet)
later. Unfortunately it was later or I would have
suggested it.

Why the jihad (and I'm using the word advisedly)
against the map, filter and reduce operators?
It seems to be completely irrational from my
viewpoint. I've seen the arguements, and they
make no sense.

> BTW, I think "large and stable" would have been less offensive than "fat 
> and happy", but perhaps you meant to imply we're both lazy and complacent, 
> rather than just satisfied with something that works and not inclined to 
> shoot for moving targets every working day.  If so, I'm not sure why you'd 
> say that, since the evidence doesn't support it.

I'm not suggesting shooting at a moving target. I'm suggesting
getting the head out of the sand, looking at trends, and figuring
out the _large_ steps to take next, not the nickle and dime fixups
that are the only things I see in PEP 3000. (Not to say that some
of them aren't going to be a lot of work. Some of them are.)

I came back from Agile2005 last week. The open space session
on Ruby was maybe 5 times as large as the one on Python. And
both of them were kind of an afterthought. Look at the OSCon
blogs. There were a number of hardcore Python people there.
They couldn't get into Ruby sessions because they were jammed.
Standing room only.

There's a report out that the "scripting languages" in general are
losing mindshare big time in Europe, Africa and the east in general.
In fact, everywhere except in North America. I'm generally somewhat
skeptical of these reports unless I can see the  methodology, but it's
definitely a data point.

Another thing that stands out: the explicit versus dynamic typing debate
has moved on from program correctness (which is a wash) to
other areas that explicit (or derived) type information can be used
for. I see this in PyFit: the languages where explicit type information
is available by reflection have cleaner implementations. The languages
with dynamic typing all have to deal with the fact that they can't get
type information by reflection, and it's a diverse mess.

The world is moving on, in ways that I think you're not seeing.
And Python is standing still in many of those same ways.

John Roth





John Roth

>
>
> -Peter