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