Python syntax in Lisp and Scheme

[Alex Martelli]

Grzegorz Chrupa?a wrote:
   ...
> I have some doubts about the notion of simplicity which you (or Guido)
> seem to be taking for granted. I don't think it is that straightforwrd to
> agree about what is simpler, even if you do agree that simpler is better.
> Unless you objectivize this concept you can argue that a "for" loop is
> simple than a "map" function and I can argue to the contrary and we'll be
> talking past each other: much depends on what you are more familiar with
> and similar random factors.

I have both learned, and taught, many different languages -- and my
teaching was both to people already familiar with programming, and to
others who were not programmers but had some experience and practice
of "more rigorous than ordinary" thinking (in maths, physics, etc),
and to others yet, of widely varying ages, who lacked any such practise.

I base my notions of what is simple, first and foremost, on the experience
of what has proved easy to teach, easy to learn, and easy for learners to
use.  Secondarily, on the experience of helping experienced programmers
design, develop and debug their code (again in many languages, though
nowhere as wide a variety as for the learning and teaching experience).

None of this (like just about nothing in human experiential knowledge about
such complicated issues as the way human beings think and behave) can be
remotely described as "objective".


> As an example of how subjective this can be, most of the features you
> mention as too complex for Python to support are in fact standard in
> Scheme (true lexical scope, implicit return, no expression/statement

Tut-tut.  You are claiming, for example, that I mentioned the lack
of distinction between expressions and statements as "too complex for
Python to support": I assert your claim is demonstrably false, and
that I NEVER said that it would be COMPLEX for Python to support such
a lack.  What I *DID* say on the subject, and I quote, was:

"""
Python draws a firm distinction between expressions and
statements.  Again, the deep motivation behind this key
distinction can be found in several points in the Zen of
Python, such as "flat is better than nested" (doing away
with the expression/statement separation allows and indeed
encourages deep nesting) and "sparse is better than dense"
(that 'doing away' would encourage expression/statements
with a very high density of operations being performed).
"""

Please read what I write rather than putting in my mouth words that 
I have never written, thank you.  To reiterate, it would have been
quite simple to design Python without any distinction between 
expressions and statement; HOWEVER, such a lack of distinction
would have encouraged programs written in Python by others to 
break the Python principles that "flat is better than nested"
(by encouraging nesting) and "sparse is better than dense" (by
encouraging high density).

> distinction) and yet Scheme is widely regarded as one of the simplest
> programming languages out there, more so than Python.

But does encourage nesting and density.  Q.E.D..

> Another problem with simplicity is than introducing it in one place my
> increase complexity in another place.

It may (which is why "practicality beats purity", yet another Zen of
Python principle...), therefore it becomes important to evaluate the
PRACTICAL IMPORTANCE, in the language's environment, of that "other
place".  All engineering designs (including programming languages)
are a rich tapestry of trade-offs.  I think Python got its trade-offs
more nearly "right" (for my areas of interest -- particularly for large
multi-author application programs and frameworks, and for learning
and teaching) than any other language I know.

> Specifically consider the simple (simplistic?) rule you cite that Python
> uses to determine variable scope ("if the name gets bound (assigned to) in
> local scope, it's a local variable"). That probably makes the
> implementor's job simpler, but it at the same time makes it more complex
> and less intuitive for the programmer to code something like the
> accumulator generator example -- you need to use a trick of wrapping the
> variable in a list.

It makes the _learner_'s job simple (the rule he must learn is simple),
and it makes the _programmer_'s job simple (the rule he must apply to
understand what will happens if he codes in way X is simple) -- those
two are at least as important as simplifying the implementor's job (and
thus making implementations smaller and more bug-free).  If the inability
to re-bind outer-scope variables encourages all programmers to use
classes whenever they have to decide how to bundle some code and some
data, i.e. if it makes classes the "one obvious way to do it" for such
purposes, the resulting greater uniformity in Python programs is deemed
to be a GOOD thing in the Python viewpoint.  (In practice, there are of
course always "other ways to do it" -- as long as they're "non-obvious",
that's presumably tolerable, even if not ideal:-).


> As for Ruby, I know and quite like it. Based on what you tell me about
> Python's philosophy, perhaps Ruby makes more pragmatic choices in where to
> make things simple and for whom than Python.

I thought the total inability to nest method definitions (while in Python
you get perfectly normal lexical closures, except that you can't _rebind_
outer-scope names -- hey, in functional programming languages you can't
rebind ANY name, yet nobody every claimed that this means they "don't have
true lexical closures"...!-), and more generally the deep split between
the space of objects and that of methods (a split that's simply not there
in Python), would have been show-stoppers for a Schemer, but it's always
nice to learn otherwise.  I think, however, that deeming the set of
design trade-offs in Ruby as "more pragmatic" than those in Python is
a distorted vision, because it fails to consider the context.  If my main
goal in programming was to develop experimental designs in small groups,
I would probably appreciate certain features of Ruby (such as the ability
to change *ANY* method of existing built-in classes); thinking of rather
large teams developing production applications and frameworks, the same
features strike me as a _negative_ aspect.  The language and cultural
emphasis towards clarity, simplicity and uniformity, against cleverness,
terseness, density, and "more than one way to do-ity", make Python by
far the most practical language for me to teach, and in which to program
the kind of application programs and frameworks that most interest me --
but if my interest was instead to code one-liner scripts for one-off
system administration tasks, I might find that emphasis abominable...!


Alex