On Mon, 19 Mar 2012 09:02:06 +1100, Chris Angelico wrote: > On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <lada...@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.
I'm sorry, I don't understand what part of John's sentence you mean by "this". "Programmers"? "Value"? "Understand"? > 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; 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 :-) 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" In assembly language, not so much. I wouldn't even have begun to guess how to assign variables in assembly, or even whether such a thing is possible, but a few minutes of googling gave me this: # 8086 assembly x dw 1234 y db 'Hello', 0 # MIPS assembly x: .word 1234 y: .asciiz "Hello" I don't know about anyone else, but I wouldn't have guessed that the way to get x=1234 was with "x dw 1234". What's more, with Python, one example hints on how to do other examples. Having seen x=1234, most people would guess that x=1.234 would also work. I'm pretty sure that "x dw 1.234" will do something surprising, although I don't know what, but it certainly won't be to assign the float 1.234 to a variable x. So there we have another measure of "readability" -- discoverability. Having seen one example, how easy is it to predict slightly modified examples? In assembly's case, not very predictable. What's the difference between these two lines? a db 127 b db 327 For that matter, what will the second line actually do? The thing is, these aren't "advanced features" of assembly language. It's not like trying to understand metaclasses in Python. These are the basic foundations. You can read vast swathes of simple Python code without needing to learn the gory details of Python's data model (name binding of objects, everything is an object), but you can't even *begin* reading assembly language without a good grasp of the data model and jargon. Assembly has a very steep learning curve. Python has a shallow curve. Here's another indication of readability. There have been occasional suggestions on Wikipedia that they standardize on Python as "executable pseudo-code" for code samples. Now replace "Python" with assembly language. Unless you're Donald Knuth, the idea is ridiculous. Another factor related to readability is the primitiveness of the toolset. Assembly has a very low-level, primitive toolset. How would you write this in assembly? print(sorted(somelist)) 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. "How do I build a tree house using nothing but a hammer?" I'm sure that, given sufficient ingenuity, you could build a tree house with nothing but a hammer, lumber and nails, but the detailed instructions would be complicated and difficult. How much simpler it becomes with a more powerful set of tools. Assembly is simple, like a hammer. (Well, perhaps not *quite* as simple as a hammer.) > 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? 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. On this measure, Python has actually become *less* readable in recent years, with the addition of powerful new idioms such as generators, list comprehensions, with statement, etc. They are very expressive, and Python is much better off with them, but they are less readable in the sense I am talking about: readable to somebody who is not an expert in the language. For this reason, when dealing with beginners, or writing code intended as "executable pseudo-code", I try to stick with features that worked in Python 1.5 where possible. E.g. for-loops rather than list comprehensions. > 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. 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 :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
