Python is readable

[Steven D'Aprano]

On Mon, 19 Mar 2012 15:33:51 +1100, Chris Angelico wrote:

>> This is at least the second time you've alleged that assembly language
>> is more readable than Python. I think you're a raving nutter, no
>> offence Chris :-)
> 
> None taken; guilty as charged. And unashamedly so. With that dealt with,
> though: My calling assembly "readable" is a form of argument by drawing
> to logical, but absurd, conclusion - by the given definition of
> readability, assembly is readable, ergo the definition sucks. (That's a
> term all logicians use, you know. Proper and formal jargon.)

Which definition of readability are you using? Because I have given, if 
not a formal definition, at least a good explanation of what I consider 
to be the usual meaning of "readability" in the context of programming 
languages. I haven't seen anyone propose an alternative.

Readability, as I see it, is a misnomer. What people actually mean by 
"Ruby is more readable than Forth" (say) is that Ruby is more 
comprehensible to some idealised non-expert reader. I also gave a list of 
characteristics of this idealised reader -- check the archives.

I don't see how "assembly is readable" is the logical conclusion of my 
definition. It certainly is the logical conclusion if you make expert 
practitioners in the language as the judge of readability, but that's not 
my argument, that's yours.


>> Assignment (name binding) is close to the absolute simplest thing you
>> can do in a programming language. In Python, the syntax is intuitive to
>> anyone who has gone through high school, or possibly even primary
>> school, and been introduced to the equals sign.
>>
>> x = 1234
>> y = "Hello"
> 
> Not quite. In mathematics, "x = 1234" is either a declaration of fact,
> or a statement that can be either true or false. 
[snip differences between assignment and equality]

Granted there are differences. Nevertheless, even mathematicians have a 
form of assignment, using almost the same notation many programming 
languages use:

let c = 42

Sometimes the "let" is left out.

The point is not that programming assignment and mathematical equality 
are identical, but that most people have been exposed to maths = in 
school and so can intuit the meaning of programming = .

Admittedly not always *correctly* :)


[...]
>> Assembly has a very steep learning curve. Python has a shallow curve.
> 
> Of course. But computer programming generally has a fairly stiff
> learning curve; you have to get your head around all sorts of concepts
> that simply do not exist anywhere else.

Sure. That brings us to the perennial conflict between power/
expressibility versus readability/comprehensibility. Except for languages 
aimed purely as a teaching language for beginners, or perhaps an 
application scripting language, readability should not be the *only* aim 
in a language. The trick is to add as much power as you need without 
losing too much readability.

The more powerful an abstraction or programming construct, the less non-
experts will be able to intuit what it does. Or for that matter, the less 
likely they will be able to understand it even after explanations. I 
still have no idea what Haskell monads are.

Contrariwise, the simpler and more comprehensible a tool is for non-
experts, the less likely it will be interesting to experts. Either there 
will be too much syntactic sugar (e.g. "add 3 to x" instead of x += 3) or 
it simply won't do much ("x + 3" is understandable but not very 
interesting, and it doesn't help you talk to a database).

Somewhere between those extremes of Forth and Hypertalk is a happy 
medium. It is my position that Python is somewhat closer to that peak 
than close neighbours like Ruby and Javascript, but I'm willing to accept 
that a certain amount of that is mere personal taste.

Of course my personal taste is right and theirs is wrong.

*wink*


>> If all you have is a hammer, the instructions you get are easy to
>> understand because there's not much you can do with it. How complicated
>> can "hit the nail with the hammer" get? But the right measure is not
>> the simplicity of the tasks you *can* do, but the comprehensibility of
>> the tasks you *want* to do.
> 
> Right, which is why NO language can be described as "readable" or "easy
> to work with" unless you define a problem domain. SQL is an excellent
> language... as long as you want to query a relational database.

And so long as you stick to simple examples, it is relatively 
comprehensible:

SELECT COLUMN2 FROM TABLE WHERE COLUMN1 = 42;

But then you have stuff like this:

SELECT * FROM (
  SELECT
    RANK() OVER (ORDER BY age ASC) AS ranking,
    person_id,
    person_name,
    age
  FROM person
) foo
WHERE ranking <= 10

Try asking your dear ol' granny to explain what that does.


>> The measure of the readability of a language should not be obfuscated
>> or badly written code, but good, idiomatic code written by an
>> experienced practitioner in the art. Note that there is a deliberate
>> asymmetry there: when judging "readability" (comprehensibility), we
>> take idiomatic code written by somebody who knows the language well,
>> and give it to a novice to interpret it.
> 
> Sure. You can write bad code in any language, and that doesn't mean
> anything. But still, if you're writing for a novice, you write quite
> different code from what you'd write normally. Language tutorials are
> written by experts for novices; language tutorials do not look like the
> language's own standard library (assuming it has one written in itself).

Absolutely.

One of my pet peeves is the number of people who give answers to 
questions *far* over the experience level of the person asking the 
question. Like if Joe Noob asked how to read a number from three files 
and calculate the sum, and I gave an answer involving spawning a bunch of 
threads to read the files.

If your aim is to *teach*, then "that's how I would do it" is not 
necessarily a good answer is the person you are trying to teach knows 
less than you.


>>> Really, the metric MUST be Python programmers. Intuitiveness is of
>>> value, but readability among experienced programmers is far more
>>> useful.
>>
>> But by that metric, Brainf*** is readable, since an experienced expert
>> in the art of writing BF code will be able to recognise BF idioms and
>> interpret them correctly.
> 
> Not really. The BF code to do one simple high level operation could
> easily span several pages. You can't "recognize" those. Now, BF with
> macros/subroutines might be more plausible - if you could define a new
> opcode that represents some huge slab of BF code and use that - but in
> its native form, I don't think anyone could recognize what BF is doing.

Dude, there are people who can recite pi to ten thousand digits, or tell 
you the 23rd phone number on page 348 of the White Pages from memory. 
Somewhere out there is a guy who can glance at eight pages of BF code and 
tell you what it does and where the bugs are.


>> No, I'm sorry, I disagree that the standard of readability should be
>> the experienced programmer. By that standard, "readability" is a no-op.
>> All languages are, more or less, equally readable, to those who can
>> read them well. I don't think it is useful to judge the readability of
>> Forth on the ability of Charles Moore to read it. How does that help me
>> decide whether to use Forth for my next project?
>>
>>> 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;
>>
>> Then he hasn't learned the language *sufficiently well*. Either that,
>> or your code is obfuscated, unidiomatic crap. Perhaps you're trying to
>> write BF in Python :)
> 
> And that's where the nub of the question is. How well is sufficiently
> well? Clearly you do not require your code to be comprehensible to a
> non-programmer, or you would not write code at all. If you don't demand
> that the reader learn basic keywords of the language, then it's equally
> impossible to expect them to comprehend your code. If you're writing
> production code, I see no reason to avoid language features like
> Python's list comps, Pike's %{ %}  sprintf codes, or C's pointer
> arithmetic, just because they can confuse people. Learn the language,
> THEN start hacking on the code.

Certainly. I don't mean to imply that code should always be written for 
beginners. Code is primarily written for other programmers, and only 
secondly for the compiler, so you must choose your audience. Every piece 
of code needs to weigh up many different characteristics, some of which 
are in conflict:

    * fast to run
    * fast to write
    * efficient use of memory or other resources
    * easy to add functionality
    * easy to debug
    * understandable to non-experts
    * useful
    * correct

The last two are especially interesting. Some problems can't be solved 
correctly in any reasonable timeframe, but heuristics can give an answer 
which may not be strictly correct but still useful. Many optimization 
problems are like that. Sometimes a close answer is better than no answer 
at all.


-- 
Steven