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

[Devan L]

John Roth wrote:
> "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.

Could you give examples of some of what 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

I don't see the connection between the linked article and this
discussion. Not having methods for doing things that have equivalent,
simple implementations does not make Python left behind.

> 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.

You don't *have* to follow the convention, but it makes it much easier
for other programmers to read your code.

> 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.

A GUI is not a critical part of a programming language. You only need a
GUI for end users. Not all programmers make programs for end users.

> 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.

Map and filter are not special. Why have two ways to do the same thing?
Reduce is a special case, but the arguments against map and filter are
quite sensible.

> > 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.

More people does not mean better.

> 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.

Take another look then.

-Devan L