Bob Miller wrote:
>As for the "indentation is block structure" part of Python, I disagree
>with toman. That's one of the best things about Python, and I'm
>amazed that it took so long for someone to try it. Otherwise, you're
>constantly checking that your indentation matches your curlies. I've
>flushed dozens of bugs out of C code where there's a mismatch. The
>code looks correct, but it executes something different.
>
I have too, which is why I don't trust the indentation, I trust the
braces. Worse than that is
python, where there are no braces to trust. I have flushed dozens of
bugs in python where
tabs turned to spaces or the other way around in the editor and what I
thought I saw wasn't
really there, or been interrupted while editing (block indenting) code
and found that without
analysis I couldn't tell whether a line should be in a block or right
after it. The usual response
to this is to blame the editor (or the sun, moon, anything else besides
the language), but ultimately
your code is dependent on something you can't see. I was indenting code
quite nicely before I started
working in python, I don't need someone else's idea of good formatting
imposed on me, particularly
when it hinders me instead of helps. And I've never seen a good
rationale for leaving the colons in if
whitespace works so well to indicate block structure. Plus (now you've
got me started;-) python code
on the printed page is meaningless because there is no sense of indent
and dedent on paper,
or a zero to judge them by. BUT BESIDES THIS ONE GLARING FLAW it's my
language of choice.
>The analogy with Fortran IV is false, because Fortran, as most people
>practiced it back in the Bronze Age, had no block structure.
>
>
??? Yes it did. FOR loops, IF THEN ELSE ENDIF conditionals, they sure
looked like blocks when
I was writing them. My point was that anyone who has written enough
fortran knows what a headache it is to have
whitespace have meaning in their code. like accidentally starting in
column 6 and having the first
character taken as a continuation line, or going past column 72 and
having your expression truncated.
It's just a real bad idea to have meaningful things be invisible or
obscured (like static variables in the middle of a C function).
Programming is hard enough without that.
J. Toman
_______________________________________________
Eug-LUG mailing list
[EMAIL PROTECTED]
http://mailman.efn.org/cgi-bin/listinfo/eug-lug