On Fri, 2008-09-12 at 14:24 -0600, Adam Olsen wrote:
On Fri, Sep 12, 2008 at 1:29 PM, Cliff Wells
wrote: 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.
Again, a vast difference in what we consider complexity.
Well there's two forms of complexity to consider: language complexity and user-program complexity. A language that's too simple (e.g. assembler or C) can lead to an explosion of complexity when actually used to develop a non-trivial program. I'd actually agree that language features help reduce program complexity. For instance even the simple case of Python lacking the equivalent of repeat..until or do..while loop forces a tiny bit of complexity (in the form of a couple extra lines of code and usually an extra exit point from a loop) into a user's programs. The complexity I'm referring to is the fact that Python's collection of statements are rapidly forking into two forms: the original statement form, and newer expression forms. Worse, in some cases these expression forms exist in several sub-forms (e.g. list comps, expression comps, generators, etc). These forms all have a single common *logical* operation in mind (looping), but mutate into other forms because they are too specialized. It's also worth noting that most of them use an inverted syntax from the original statement in order to help distinguish them. I'm claiming that a single more flexible construct could potentially be used in place of all of them (for-expression with yield), and further, I'm claiming this is a case where simplifying the language would not complicate the user's program and in many cases might help to simplify it.
For a user, does it matter that we use "len(foo)" rather than "len foo"? A little bit, but it's not huge.
Or more consistently foo.len() which we *almost* have except it's spelled __len__ :P I agree this is a minor nit, but also rather pointless as far as I can tell.
For the language developers, does it matter? Again, it's a small benefit. It's still our job to design it, not a third-party. Syntax and stdlib are both part of the language.
All the things you think we might avoid by being more "functional", we'd still have to do them, saving nothing. Except all the details suggest *worse* solutions would be found, as we wouldn't be fine-tuning the syntax for the use-cases.
The only genuine use-case for your changes I've seen in this whole thread is the dispatch-dict, but your changes are far too distract to justify it.
I'm not surprised. In fact, after programming in Python myself for a decade or so I'm surprised I was able to find any suitable example ;-) The Sapir-Whorf hypotheses predicts this. A Lisp or Haskell programmer would probably be much better armed than I to provide concrete examples. Even if you don't subscribe to Sapir-Whorf, I think you could probably agree that at least the lack of idioms for FP in Python would contribute to our mutual inability to visualize particularly useful examples.
As an aside, I can't speak for Guido, but I haven't seen any indication python's development process may collapse. It's a non-problem.
I didn't mean the development process may collapse, I mean the rejection process may collapse due to pressure (and I believe it has already on occasion). Regards, Cliff