On 02/09/2013 23:04, Andrew Barnert wrote:
> From:Rob Cliffe <rob.cliffe(a)btinternet.com>
> Sent:Monday, September 2, 2013 8:29 AM
>> You seem to have replied just to me, not to the list, which is a pity, because it means this reply is going just to you.
> Your last message was just to me, so I didn't think you wanted it going to the list.
Sorry, my mistake, I'm attempting to copy this to the list now.
>
>>>> What do you think is easier and quicker to write (or indeed, to understand, if you're not a Python expert)? Say at 1am when you're trying to meet a deadline and keeping awake with coffee?
>>> I can write either one easily.
>> OK, you can. (How many years have you been programming in Python?) That does not mean that everybody can. (I can too but maybe not as easily as you. But I might write it in my simple way at first, to get it working, then come back later and smarten it up.)
> Novices looking for help on Stack Overflow can create dictionaries. My coworker who just learned Python over the last two months can. This is in the tutorial, it's not some deep magic for experts only.
>
>>> The question is which one I can write without making a stupid mistake that I'll have to debug six weeks later. Less repetition and less visual noise means fewer places to make a mistake, and easier to spot it when you do.
>
>> But the very repetition (and vertical alignment) mean that many of the possible mistakes stand out like a sore thumb. The human brain is good at seeing patterns.
> Repetitive code is exactly where people make the most mistakes. And if you've ever debugged any serious project, it really can be hard to notice that you used ssock instead of csock in one of eight near-identical blocks of code. If you just write one block of code instead of eight, it's impossible to make that mistake in the first place.
But if the csock s are vertically aligned, the mistake stands out.
>> My version (boring, repetitive, unimaginative ... but simple and straightforward),
> or something involving dictionaries, lambda functions, and having to look up the docs (I didn't actually know about __contains__ or operator.contains) ?
>>> The whole point of programming is using your imagination to eliminate boring, repetitive, and simple tasks.
> Er, no. No. The point of programming varies. And "good" and "bad" code do not exist in isolation, context matters too (commercial environment? academic?).
>
> No, it really doesn't. Except for learning and language-research purposes, when you write a program, it's to accomplish something that otherwise you or another person would have to do manually, which would be tedious, or difficult, or error-prone. You could go through a spreadsheet and count up the number of unique users (column 3) in each state (column 2), but it would take days, and you'd make dozens of mistakes, and you'd be miserable. Or you could write a program in a few minutes or hours.
>
>>>> Obviously this is a judgement call, but I know what my view is.
> As a touchstone: my version could be rewritten in just about any other language with minimal effort, just because it is so simple and uses no "tricks". How many languages could yours be rewritten in as quickly (assuming you're not already an expert in the target language) ?
>>> Putting functions into a dictionary is not some advanced "trick", it's a basic idiom. It's used in the tutorial, the FAQ, the stdlib, etc.
>> Sure it is (in Python). But if I wanted to translate this code into another language (especially in a hurry), I would (as I said before) need minimal knowledge of that language to translate my boring version. (LISP?)
True but is does add one level of abstraction, and one's brain has to go
through that level to understand the code. The more levels of
abstraction, the less intuitive and harder to understand code becomes
(look at Twisted, possibly the ultimate example).
> Why would you need to translate it into another language in a hurry?
Who knows? We live in an unpredictable world; we adapt to it or die.
If I could predict all the things my manager asks me to do ... well, I
guess I wouldn't need a manager.
>
>> We have got a bit bogged down discussing this particular example
> (partly my fault). I was simply trying to make the point that there
> may be circumstances when it is OK, even a good thing, to put 2, 3
> or (heaven forbid) 4 statements on a single line, and to illustrate
> the point with a couple of examples. That (you find that) the
> examples are less than perfect does not, in itself, mean that my
> point is entirely wrong.
>
> I said right at the beginning that your code isn't terrible; you're the one who insisted that other people will say it is.
>
> And there are certainly examples where writing two statements on a line makes sense. I have code like this:
>
> if stop: break
>
> x += a; y += b
>
> So I agree with you that sometimes putting multiple statements on a line is a good thing.
Good. I also quite often (not always) write 1-line if-suites like that
(as in my first example). I'm glad we agree on something.
> But doing it so you can avoid using one of Python's fundamental features because you're afraid you might have to translate the code to a language you barely know is not a good reason to do it.
We'll have to disagree on that. I think sometimes it might be. But my
primary motive was to write the code so that it was simple to write and
simple to understand.
Another (invented) example occurred to me (before I saw yours above):
Version 1:
x1 += 1
x2 += 1
x3 += 1
y1 += 1
y2 += 1
y2 += 1
z1 += 1
z2 += 1
z3 += 1
Version 2 (Rob's version):
x1 += 1 ; x2 += 1 ; x3 += 1
y1 += 1 ; y2 += 1 ; y2 += 1
z1 += 1 ; z2 += 1 ; z3 += 1
In which version is it easier to grasp what this code does? In which
version is it easier to spot the deliberate mistake?
(And please don't rubbish the example by saying it should have been
written differently in the first place. Circumstances *do* alter
cases; I could be making a minor alteration to a huge inherited program
which it is not practicable or necessary to rewrite.)
Rob Cliffe
