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

[Cliff Wells]

On Sun, 2008-09-14 at 01:24 +0200, Cesare Di Mauro wrote:
> > On Sat, 2008-09-13 at 23:58, Cliff Wells wrote:
> 
> > I understand that any such change would need to be adequately defined.
> > But I don't consider the discussion to have progressed to that point.
> > If people do not even understand that expression-oriented languages
> > provide any advantage (in fact, many of them apparently consider it a
> > disadvantage), then there's little point in discussing what particular
> > syntax this apparently useless change would take on.
> 
> Are you sure that calculating and returning a value for each statement
> that is interpreted as an expression is really an advantage? I find little
> cases that shows such an advantage on real world code (one of each is the
> ternary operator, that was introduced in Python 2.5 to fill that "hole").

The particular use-case I personally have in mind is for the development
of DSL's, where the domain being modeled is most naturally expressed as
nested expressions.  There are many other uses and frankly many of the
things we currently use objects for could arguably be more naturally
expressed functionally.  

Honestly, I think it's very difficult for a person who's grown
accustomed to a procedural style to grasp the potential here (and I
certainly include myself in this group, although I feel I'm starting to
see the light).

> Just to be clear, I think that returning a value after executing a for,
> while, and even an if statement/expression EVERY TIME would be of no
> pratical use except for very rare cases.

I remember this wisdom being encoded in the old adage "Lisp programmers
know the value of everything and the cost of nothing" which was a jab at
the relative slowness of Lisp compared to C.  However the same argument
could be made for almost any aspect of a dynamic interpreted language.
I don't have any supporting data, but I strongly suspect the cost would
be almost immeasurable compared with the cost we've already incurred to
have the features we consider indispensable.  

Also, it's worth noting that in the majority (actually, I'd expect
nearly all) of cases the value is already calculated, it simply isn't
returned.  I think that overhead would be minimal. 

> Consider that you have to spend resources (CPU and memory) calculating
> values, that most of the time will be trashed because they will not be
> used.
> 
> I know that we already have functions that work the same way: they always
> return something, defaulting to None when no return statement is used.
> That's because Python has only a "function" type (contrary to Pascal,
> which distinguish between functions and procedures), but I think that
> Guido opted to reduce the complexity of the language giving just one
> subroutine invocation type to use.

I believe that was a good choice.   Speaking of Pascal (which was the
second language I learned), I think there's a good parallel to be drawn.

When I was learning pointers in Pascal, I struggled badly.  I assumed it
was because pointer manipulation was difficult.  Then I learned C, and
discovered that in that language, pointers were so natural that I picked
up in a day what I couldn't put together properly in weeks or months in
Pascal.  Pascal wanted to abstract away the machine and how data is
stored, which is anathema to pointers.  C, on the other hand presented
data in a way that made pointers natural.

On the other hand, when I started doing OO programming in C (yes, it can
be done, to a limited degree), I was again in the same boat.  I was able
to make it work, since I was much more expert in C than I ever was in
Pascal, but overall the experience made me realize that OO support in a
language is a good thing ;-)  You can fake OO with structs and pointers
but it feels like a hack, even though it's kind of a satisfying one.

Today, you can do a fair amount of FP in Python, but it feels unnatural.
Even if you get your code to work as you want it probably won't appear
elegant.  You can fake some FP constructs with OO but again, it's really
only a workaround, no matter how clever it might make you feel (in fact,
I'd go so far as to suggest that if your code makes you feel clever,
then you've just performed a workaround).

> Do we really need to slow down the language (at the cost of less
> readability too, because I'm strongly convinced that using statements like
> expressions will reduce it) for such limited "added value"?

I think reduced readability is perhaps the strongest argument against FP
style.  However, even OO presents this danger and yet we embrace it
fully.  I wish I could remember who this quote is attributed to (and the
exact phrasing for that matter):

"The danger of the fully realized object is that it appears ordinary"

OO presents a very arguable danger of making code impenetrable and yet
we rarely experience this problem in real life, and in fact find quite
the opposite: many things are most naturally expressed in an object
paradigm.   Given that expression-oriented languages haven't collapsed
in large-scale applications (in fact they have flourished) should be
fair indication this perceived danger doesn't necessarily have to be
reality in this case either.

Overall, I think a language should trust the programmer to know what he
wants to do in his own program and that he's the one who's best able to
decide what paradigm best suits the domain at hand.

Regards,
Cliff