On Fri, 2008-09-12 at 09:51 -0700, Josiah Carlson wrote:
On Fri, Sep 12, 2008 at 8:55 AM, Cliff Wells
wrote:
Agreed, and I had intended to move to that stage once I felt there was a consensus that there is actually something that needs solving. What I failed to make clear in my position is that I'm not trying to add a feature for a it's own sake, rather that the current process for limiting the growth of the Python language is doomed to failure.
The growth limiting mechanism is doomed to failure, or the language is doomed to failure?
I'm asserting that the limiting mechanism is doomed to failure.
I'm going to try to rephrase the fundamental problem I see here and hopefully I won't fail so dismally this time:
1) I assert that small is better than large when it comes to limiting complexity.
It would seem that you are saying that limiting Python's complexity is a bad thing. Please correct me if my understanding of your statement is incorrect.
No, I'm saying limiting complexity is good and that smaller is better.
I'm personally of the opinion that limiting the complexity of Python as a language is a good thing. And so far, I think Guido has done a fairly very good job at keeping Python moving in a positive direction.
Yes, but I also feel that the language has already grown to a point where only a shrinking subset of Python users fully know and understand the full feature set. For people who have been using Python for many years, they've possibly had time to digest the new features. I don't believe new users fare as well.
2) The primary method of limiting Python's core feature growth is for the BDFL to dig in his heels and reject ideas until they are adequately shown to be broadly needed and implementable.
3) This method has failed in the past*. In fact, I assert that this method is guaranteed to fail unless all ideas that add syntactical structures are rejected outright, regardless of their utility. It cannot limit the growth of Python's core, it can only limit the rate at which it grows.
If the rate of language feature growth is slowed by Guido, then obviously the growth of Python's core language is limited.
A slow boat still reaches its destination. My position is that by obviating the need for a large class of syntax extensions, the onus is moved from the Python core team onto the user desiring a particular extension and by doing so, things like community pressure to add X can be reduced and by extension, the likelihood of the process folding under that pressure becomes much less likely.
I would argue that this is a good thing, as the more language syntax and features that are present, the steeper the learning curve for new users of the language.
Absolutely. But this isn't what Python has been doing (as you acknowledge below). We seem to be agreeing on this point, so I believe our disagreement must center around whether the current process continues to be sufficient.
Python 2.5.2 is a wholly different beast from the Python 1.5.2 that I started with, but I've had nearly 10 years to update my understanding of the language. For new users? Metaclasses, list comprehensions, generator expressions, generators, ... I get asked about them all. And the language keeps growing!
I switched from C to Python right as 1.5.1 was being phased out. To this day I continue to use a subset of Python that is probably much closer to 1.5.x than 2.5. This may be attributed to a personal failing (my self-professed laziness), but the fact remains that I prefer a small, versatile set of constructs to a large set of specialized ones. C, for all of its shortcomings, had one absolutely compelling feature: you could keep the entire language in your head and you could do it in an amazingly short time. Python 1.5 was similar in scope. 2.5 is arguably at or beyond that limit for most people.
4) As Python moves into new domains, as new programming languages come into vogue, and as the art of programming itself advances (albeit glacially), users will perceive needs in Python and will clamor for extensions. Some of these will eventually be accepted.
But not all. Why? Because not all proposed extensions to Python are worth discussing outside of a water-cooler "wouldn't it be neat if?" discussion. See the proposed extension to list comprehensions where "order by" was proposed from sql (a year or two ago at this point). That shouldn't have even made it to python-dev. Yet it did. Why? Because everyone has their "I really want X", and too few people are willing to acknowledge that they can be wrong.
Right, but I am suggesting that perhaps at least some of this problem (the need users feel for extensions) is currently built into the language. I also made this point to bolster my argument that feature-creep is inevitable. Outside of the object unification that's been happening over the last few years, most of the features being added to Python appear to be oriented to supporting the FP paradigm (generators, list comps, ternary if, etc). However these features appear to be added in an ad hoc fashion. I'm not suggesting they weren't thought out, only that they were added based on demand rather than as part of an overall plan as the object unification was. It appears to me that most of these "water-cooler" suggestions are proposed precisely because a) Users encounter a situation where an elegant solution isn't obvious and they feel they must resort to magic and hackery. b) The elegant solution they were looking for is embodied as an extension or requires knowledge that is more advanced than the problem at hand would seem to require (e.g. metaclasses). c) The PEPs (or more commonly, the flamewars on c.l.py) begin. For example, earlier in this thread you provided an elegant solution to what appeared (to myself and at least one other person) to be an intractable problem. But of course, it wasn't the natural solution to most people. It's ironic, because I've actually used a similar solution before, but wasn't able to see it this time. In fact, every time I have to use it, I have to reinvent it because it isn't the natural way the problem is expressed. The problem is most naturally expressed procedurally but must be solved with an OO paradigm.
5) Given the added desire to maintain backwards-compatibility, old features will not be shed as fast as new ones are added (unless that becomes part of the process, which doesn't seem practicable to me).
Python 3.0 is one of the ways that features are shed. While Guido has stated that he doesn't believe that there will be a Python 4k (aka Python 4.0) that hits the reset button again, I think that there needs to be one, so that Python *can* get rid of bad features that we were wrong about. There's also the PEP process, which as long as there isn't sweeping "break everything" changes, it would seem that we can remove features as time goes on.
Sure, and I think this is a valuable process.
6) I believe that a large class of these features could be rendered moot or redundant if the language embraced a more sweeping and fundamental change. While this won't absolutely prevent the language's growth, it provides a built-in deterrent.
...To a functional programming paradigm. That's what you meant to say, right?
Yes, although by "to" I would mean "allow for" rather than "convert to". In other words, not convert to or even encourage the FP paradigm, but also not prevent it. It would be embracing multi-paradigm approaches rather than abandoning one in favor of another. Python has always been multi-paradigm to an extent (procedural and object), but has always been somewhat adverse to the functional paradigm (aside from a few helpful things). Before Python's object unification efforts, many OO purists declaimed Python because its hybrid approach. Pythonistas claimed that they were wrong because "practicality beats purity", etc. But of course, we've all seen that to a large degree they were right. Practicality might beat purity, but practicality plus purity trumps both. Functional programming is, in fact, simply the logical extension of procedural programming (or more precisely, procedural is a subset of functional). They are in no way mutually exclusive. Much as Python's OO was hampered by distinctions between builtin classes and user-defined classes (amongst other things), so is Python's procedural support hampered by it's rejection of the functional paradigm.
There's an old quote by Larry Wall: "Perl is ugly because people wanted it that way". Perl took the same approach to limiting features that Python does, with the notable difference that Larry didn't reject ideas as consistently as Guido (or apparently at all). Nevertheless, we're now simply discussing the *rate* at which the language becomes large and inconsistent rather than whether it will or not.
If we agree that the issues I outline above are valid, then I think we can start bickering over possible solutions and how those solutions would affect Python on the whole.
I don't agree.
Well, that's a start. Regards, Cliff