[Python-ideas] Statements vs Expressions... why?

[Adam Olsen]

On Fri, Sep 12, 2008 at 9:34 PM, Cliff Wells <cliff at develix.com> wrote:
> On Fri, 2008-09-12 at 14:24 -0600, Adam Olsen wrote:
>> On Fri, Sep 12, 2008 at 1:29 PM, Cliff Wells <cliff at develix.com> 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.

At most, it's a *small* benefit to the language.  It comes a tradeoff,
just like a+b rather than add(a, b), or len(x) rather than x.len().  A
little bit more syntax to learn, which increases the learning curve
(but for easy enough syntax the underlying operation is more to learn
anyway), and in exchange it makes things easier for a skilled
programmer.

You're claiming we don't have to make that tradeoff.. but you've done
*nothing* to substantiate that.  Even logix only adds more complexity,
rather than removing and unifying existing syntax.

We don't care about purity.  Statements vs expressions.. functional vs
imperative.. they're tools, pure and simple.  We switch back and forth
as appropriate.  Most of the time quietly, subtly, such that you
usually don't even notice we've done it.  We like it that way.

You'll be a lot more productive if you learn to relax, concerning
yourself with use-cases, not ideals.


-- 
Adam Olsen, aka Rhamphoryncus