Flat-schmat! [was Re: Python syntax in Lisp and Scheme]

Kenny Tilton ktilton at nyc.rr.com
Sat Oct 4 14:55:57 EDT 2003


Alex Martelli wrote:

> record as promising that the major focus in the next release
> of Python where he can introduce backwards incompatibilities
> (i.e. the next major-number-incrementing release, 3.0, perhaps,
> say, 3 years from now) will be the _elimination_ of many of
> the "more than one way to do it"s that have accumulated along
> the years mostly for reasons of keeping backwards compatibility
> (e.g., lambda, map, reduce, and filter, 

Oh, goodie, that should win Lisp some Pythonistas. :) I wonder if Norvig 
will still say Python is the same as Lisp after that.

> 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).

In Lisp, all forms return a value. How simple is that? Powerful, too, 
because a rule like "flat is better than nested" is flat out dumb, and I 
mean that literally. It is a dumb criterion in that it does not consider 
the application.

Take a look at the quadratic formula. Is that flat? Not. Of course 
Python allows nested math (hey, how come!), but non-mathematical 
computations are usually trees, too.

I was doing an intro to Lisp when someone brought up the question of 
reading deeply nested stuff. It occurred to me that, if the computation 
is indeed the moral equivalent of the quadratic formula, calling various 
lower-level functions instead of arithmetic operators, then it is 
/worse/ to be reading a flattened version in which subexpression results 
are pulled into local variable, because then one has to mentally 
decipher the actual hierarchical computation from the bogus flat sequence.

So if we have:

(defun some-vital-result (x y z)
    (finally-decide
       (if (serious-concern x)
           (just-worry-about x z)
          (whole-nine-yards x
             (composite-concern y z)))))

...well, /that/ visually conveys the structure of the algorithm, almost 
as well as a flowchart (as well if one is accustomed to reading Lisp). 
Unwinding that into an artificial flattening /hides/ the structure. 
Since when is that "more explicit"? The structure then becomes implicit 
in the temp variable bindings and where they get used and in what order 
in various steps of a linear sequence forced on the algotrithm.

I do not know what Zen is, but I do now that is not Zen.

Yes, the initial reaction of a COBOL programmer to a deeply nested form 
is "whoa! break it down for me!". But that is just lack of familiarity. 
Anyone in a reasonable amount of time can get used to and then benefit 
from reading nested code. Similarly with every form returning a 
value...the return statement looks silly in pretty short order if one 
spends any time at all with a functional language.


kenny





More information about the Python-list mailing list