Python is readable

[Nathan Rice]

Just to troll the discussion a little bit more...

On Sun, Mar 18, 2012 at 6:02 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <ladasky at my-deja.com> wrote:
>> What I would say is that, when PROGRAMMERS look at Python code for the
>> first time, they will understand what it does more readily than they
>> would understand other unfamiliar programming languages.  That has
>> value.
>
> This is something that's never truly defined. Everyone talks of how
> this language or that language is readable, but if you mean that you
> can look at a line of code and know what *that line* does, then Python
> suffers badly and assembly language wins out; but if you mean that you
> should be able to glance over an entire function and comprehend its
> algorithm, then I have yet to see any language in which it's not
> plainly easy to write bad code. Even with good code, anything more
> than trivial can't be eyeballed in that way - if you could, what would
> docstrings be for?

I agree, docstrings/code comments are a pretty obvious indication that
code (as it exists currently) fails as a human communication medium.
I suppose that I could make an exception for elaboration on statement
with subtle implications.  This seems like something people should
think more about fixing.

> Really, the metric MUST be Python programmers. Intuitiveness is of
> value, but readability among experienced programmers is far more
> useful. If I write a whole lot of code today, and next year I'm dead
> and someone else has replaced me, I frankly don't mind if he has to
> learn the language before he can grok my code. I _do_ mind if, even
> after he's learned the language, he can't figure out what my code's
> doing; and that's where Python's placed itself at about the right
> level - not so high that it's all in airy-fairy conceptual work, but
> not so low that it gets bogged down. There's a handful of other
> languages that are similarly placed, and they're the languages that I
> would call "readable".

In mathematics, when you perform global optimization you must be
willing to make moves in the solution space that may result in a
temporary reduction of your optimality condition.  If you just perform
naive gradient decent, only looking to the change that will induce the
greatest immediate improvement in optimality, you will usually end up
orbiting around a solution which is not globally optimal.  I mention
this because any readability or usability information gained using
trained programmers is simultaneously measuring the readability or
usability and its conformance to the programmer's cognitive model of
programming.  The result is local optimization around the
current-paradigm minimum.  This is why we have so many nearly
identical curly brace C-like languages.

In my opinion, language readability and usability should be determined
based on the following tests:

- Given users with no programming experience:
-- What is the probability that they can correctly guess the result of
a program, and how long does it take?
-- What is the probability that they can take a program and correctly
modify it to change its output to another specified output, or modify
it to support another input representation, and how long does it take?

- Given users with no programming experience who are provided with a
controlled training period:
-- What is the probability that they can produce a program that
correctly implements a simple, completely described algorithm for
solving a puzzle or winning a game, and how long does it take?

- Given users with previous (but not extensive) programming experience
who are provided with a controlled training period:
-- What is the probability that they can produce a program that
correctly implements a simple, partially described algorithm for
solving a puzzle or winning a game, and how long does it take?
-- What is the probability that they can produce a program that
correctly implements a complex, completely described algorithm for
solving a puzzle or winning a game, and how long does it take?

It would probably also be worth examining user behavior relating to
code organization and composition under a variety of circumstances.
It seems likely that if proper organization and composition are
intuitive, productivity would scale well with program size.

> Here's an analogy: One statement (aka line of code, etc) corresponds
> to one sentence in English. Massive one-liners are like some of the
> sentences in Paul's epistles; assembly language is like "The cat sat
> on the mat". Both are valid; both are hard to read.

This is one of my gripes with the dogmatic application of the "break
it into multiple statements" mantra of Python.  Not only are you
forced to use generators to maintain semantic equivalence in many
cases, in some cases a partial statement fragment doesn't have any
intuitive meaning.  The result is that readers are forced to hold the
value of intermediate_variable in their head while reading another
statement, then translate the statement to the conceptually complete
form.  A statement should be an encoding from a conceptual space to a
operation space, and ideally the two should be as similar as possible.
 If a concept is atomic, it should not be comprised of multiple
statements.