Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.

Steve Howell showell30 at yahoo.com
Fri Feb 19 05:46:04 CET 2010

```On Feb 18, 2:49 pm, Jonathan Gardner <jgard... at jonathangardner.net>
wrote:
> On Feb 18, 8:15 am, Steve Howell <showel... at yahoo.com> wrote:
>
>
>
> >     def print_numbers()
> >         [1, 2, 3, 4, 5, 6].map { |n|
> >             [n * n, n * n * n]
> >         }.reject { |square, cube|
> >             square == 25 || cube == 64
> >         }.map { |square, cube|
> >             cube
> >         }.each { |n|
> >             puts n
> >         }
> >     end
>
> If this style of programming were useful, we would all be writing Lisp
> today. As it turned out, Lisp is incredibly difficult to read and
> understand, even for experienced Lispers. I am pleased that Python is
> not following Lisp in that regard.
>
> for n in range(1,6):
>     square = n*n
>     cube = n*n*n
>     if square == 25 or cube == 64: continue
>     print cube

There's definitely a cognitive dissonance between imperative
programming and functional programming.  It's hard for programmers
used to programming in an imperative style to appreciate a functional
approach, because functional solutions often read "upside down" in the
actual source code and common algebraic notation:

def compute_squares_and_cubes(lst):
return [(n * n, n * n * n) for n in lst]

return [(square, cube) for (square, cube) \
in lst if not (square == 25 or cube == 64)]

def cubes_only(lst):
return [cube for square, cube in lst]

def print_results(lst):
# 1. compute_squares_and_cubes
# 3. take cubes_only
# 4. print values
for item in \
cubes_only( # 3
compute_squares_and_cubes(lst))): # 1
print item # 4

You can, of course, restore the natural order of operations to read
top-down with appropriate use of intermediate locals:

def print_results(lst):
lst2 = compute_squares_and_cubes(lst)