Too much code - slicing

S

Steven D'Aprano

That wouldn't be *syntax* highlighting, that'd be *semantic*
highlighting.

Which people often do -- notice that I did it twice in that paragraph.
But that's the point -- you need to know what it *means* to make
sensible decisions about what to highlight. Syntax highlighting is
precisely the opposite, highlighting things for reasons that have
nothing to do with their semantic content. It distracts from the actual
meaning of the code.

I'm not entirely sure I agree with you here... you can't ignore syntax in
order to understand the meaning of code. Unless you understand the
syntax, even a simple line like:

x = y

is impossible to understand. Is it an assignment? If so, which way (does
it assign the value of x to the variable y, or y to x)? Or is it a
comparison?

The term "syntax highlighting" for what editors I've seen do is actually
misleading -- they don't highlight *syntax*, they try to highlight
*semantics*. When your editor highlights the function len() in the
expression "x = len(y) + spam(z)" but not the function spam(), you know
it has nothing to do with syntax. len() is singled out because of its
semantics, namely the fact that it's a built-in.


In English, the meaning of the some sentences do benefit by syntax
highlighting, and in fact that's partly what punctuation is for: English
partly uses punctuation marks as tags to break the sentence structure
into sub-sentences, clauses and terms (particularly when the sentence
would otherwise be ambiguous).

An extreme example is the infamous "buffalo" sentence, which is
grammatically valid and semantically meaningful but rather difficult to
decipher:

http://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo


Of course this is an extreme example, but English is often ambiguous, and
some sort of syntax highlighting could potentially be useful:

"Woman shoots man with crossbow"

Was it the man armed with a crossbow, or the woman? If we could somehow group the
clause "with crossbow" with "woman" or "man" by something *other* than
proximity, we could remove the ambiguity.

In ordinary English, not only does punctuation sometimes play the role of
syntax highlighting, but so do otherwise meaningless words like "the",
"a", "which", "that", "also", and so forth.

Bringing it back to Python, that's why punctuation like : are useful.
They're syntax highlighting.
 
S

Seebs

Define "unbalanced".

I'm not sure that's the word I'd use. I'm not even sure what it would mean
here.
Putting aside the over-use of punctuation, The C syntax feels unbalanced
to me. You have:
condition IF true-clause ELSE false-clause
so both clauses follow the test, that is, they're on the same side: ?--

Yes.

Just like:
if condition:
foo
else:
bar

The condition is the primary, the clauses are secondary to it.

So I like that form because it matches what I'd write if I were writing
things out more verbosely for some reason.
But the Python syntax looks balanced to me:
true-clause IF condition ELSE false-clause
which is not only plain English, but perfectly balanced, with a clause on
either side of the test: -?-

It may be balanced, but it requires you to reevaluate what you're reading
after you've already read something that seemed to have a clear meaning.

Basically, think of what happens as I read each symbol:

x = x + 1 if condition else x - 1

Up through the '1', I have a perfectly ordinary assignment of a value.
The, suddenly, it retroactively turns out that I have misunderstood
everything I've been reading. I am actually reading a conditional, and
the things I've been seeing which looked like they were definitely
part of the flow of evaluation may in fact be completely skipped.

It's even more confusing if I'm familiar with the postfix-if as seen
in, say, perl or ruby.
Python's ternary-if puts the emphasis on the true-clause, while C's
ternary-if puts the emphasis on the test. I'm not convinced that this is
necessarily a better choice than Python's. It's a *valid* choice, but
better? I don't think so, but I accept that at least partially boils down
to subjective factors.

I would usually think it better, just because most often, the *fact*
of there being a test is the first thing you have to know about the
expression to make sense of it.

If I am given the right framework first, and the information to fill into
it second, I don't have to throw away parsing I'd already done. If I'm
given information, then later retroactively told to move it into a slot
in a framework I didn't even know I was going to need, I have to do a lot
of reworking.

Consider the following lovely hypothetical syntax:

foo
bar
baz
if condition else:
blah
blah
blah

And there, at least you have some cue that you're about to see something
happen.

-s
 
S

Seebs

I'm not entirely sure I agree with you here... you can't ignore syntax in
order to understand the meaning of code.

No, but the syntax should be invisible. When I read English, I don't have
to think about nouns and verbs and such unless something is very badly
written. The syntax is handled automatically at a lower level without
conscious intervention, as it should be. Calling my conscious attention
to it is disruptive.
The term "syntax highlighting" for what editors I've seen do is actually
misleading -- they don't highlight *syntax*, they try to highlight
*semantics*.

I've never seen this. I've seen things highlight comments and keywords
and operators and constants and identifiers differently.
When your editor highlights the function len() in the
expression "x = len(y) + spam(z)" but not the function spam(), you know
it has nothing to do with syntax. len() is singled out because of its
semantics, namely the fact that it's a built-in.

Eww. (I had not yet gotten to the point of finding out that whether
something was "built-in" or not substantially affected its semantics.)
In English, the meaning of the some sentences do benefit by syntax
highlighting, and in fact that's partly what punctuation is for: English
partly uses punctuation marks as tags to break the sentence structure
into sub-sentences, clauses and terms (particularly when the sentence
would otherwise be ambiguous).

Punctuation is very different from highlighting, IMHO. That said, I
find punctuation very effective at being small and discrete, clearly not
words, and easy to pick out. Color cues are not nearly as good at
being inobtrusive but automatically parsed.
"Woman shoots man with crossbow"
Was it the man armed with a crossbow, or the woman? If we could somehow group the
clause "with crossbow" with "woman" or "man" by something *other* than
proximity, we could remove the ambiguity.

Yes. But syntax highlighting won't help you here -- at least, I've never
yet seen any editor that showed precedence relations or anything similar
in its coloring.
Bringing it back to Python, that's why punctuation like : are useful.
They're syntax highlighting.

I don't think they are, though. I think punctuation is fundamentally
different in intent and purpose from colorizing things based on whether
they're, say, constants or identifiers or comments or keywords. The
punctuation is *itself* part of the syntax -- it's not being highlighted.

Syntax highlighting is putting all the punctuation in green so you know
it's punctuation.

-s
 
A

AK

My wife can read scarily fast. It's very something to watch her reading
pages as fast as she can turn them, and a few years ago she read the
entire Harry Potter series (to date) in one afternoon, and could gives a
blow-by-blow account of the plots, including a detailed critique of the
writing style and characters. But then, she feels that reading the Potter
series is a chore to be completed as fast as possible, rather than a
pleasure to be savored. She'll sometimes drag a new Terry Pratchett or
Stephen King novel out for as much as two days.

That's pretty impressive. I used to get somewhat close to that speed
when, years ago, I'd read a lot of trashy scifi. The way it would work
is that I'd sense in advance that there's a passage where the hero with
his team is going through a desert area and I'd know that a 30-40 page
section will be punctuated by two battles and one friendly encounter. I
would be able to read at different speeds depending on what's going on,
slowing down a bit where a twist is presented or a crucial plot point is
revealed, both would be telegraphed well in advance. In other spots, I'd
be able to scan a few words at the top of page, a few in the middle and
at the bottom and I'd know what's going on, generally.

I would also be able to give a detailed account of the plot and writing
style and characters but this would be entirely due to predictability of
writing and following tropes. Interestingly, I've also read LoTR in the
same way when I was younger because I was interested in battles and
skipped the dull parts.

I tried a few times to read Potter book 3 but couldn't bear it.. spoiled
too much by Barrie and Grahame.

When I was reading The book of the new sun, though, I could stop and
read a single sentence a few times over and reflect on it for a minute.

-ak
 
A

AK

I'm not sure that's the word I'd use. I'm not even sure what it would mean
here.




Yes.

Just like:
if condition:
foo
else:
bar

The condition is the primary, the clauses are secondary to it.

To me, the problem with C ternary is, why is true condition first and
false second? It could just as well be the other way around. With if and
else, the meaning is direct, x if y else z, or if y: x; else: z.
It may be balanced, but it requires you to reevaluate what you're reading
after you've already read something that seemed to have a clear meaning.

Basically, think of what happens as I read each symbol:

x = x + 1 if condition else x - 1

Up through the '1', I have a perfectly ordinary assignment of a value.
The, suddenly, it retroactively turns out that I have misunderstood
everything I've been reading. I am actually reading a conditional, and
the things I've been seeing which looked like they were definitely
part of the flow of evaluation may in fact be completely skipped.

That's absolutely not how I read code. For example, if you have a line
like:

x = x + 1 ASF!@#$!@$ASFASF!@#$!@$#ADFASDF!@#

Do you read it as "ok, assignment.. x is x + 1.. whoa, what the hell is
this?".

I would read it like "there's something wrong at the end of line",
before I even see it as an assignment.

That's where syntax highlighting comes in, as well. What I see, at the
same time (i.e. not in sequence):

... = .. if .. else ..

The second thing I see is what variable is being assigned to. Of couse,
this might change if I'm looking for that particular variable, then I
might see:

x ................

or

x = ................

Consider the following lovely hypothetical syntax:

foo
bar
baz
if condition else:
blah
blah
blah

And there, at least you have some cue that you're about to see something
happen.

After some time getting used to it, I'd end up seeing this as:

.
.
.
if .. else:
.
.
.

at first and then processing everything else. Again, syntax highlighting
would help here. The only issue is that it'd be hard to separate the
beginning from other code, for me that'd be the primary reason why this
is not a good construct.

-ak
 
A

AK

No, but the syntax should be invisible. When I read English, I don't have
to think about nouns and verbs and such unless something is very badly
written. The syntax is handled automatically at a lower level without
conscious intervention, as it should be. Calling my conscious attention
to it is disruptive.

The interesting thing is that syntax highlight for me *is* handled at a
lower level. What you're describing is exactly the same as when I try a
highlight scheme with colours that are too strong, or have a background.
I would rather use no highlighting at all than a theme with garish
colours.

When I read code, I filter out colours when I don't need them and filter
out non-coloured text when I'm looking for a particular structure. So,
with x = y if a else z, I might see . = . if . else . and then
immediately see x . y . a . z, already with knowledge of what is the
structure surrounding vars.
Punctuation is very different from highlighting, IMHO. That said, I
find punctuation very effective at being small and discrete, clearly not
words, and easy to pick out. Color cues are not nearly as good at
being inobtrusive but automatically parsed.

Seems like the difference of how you process colours vs. how I do, for
me they work precisely in the same way as punctuation might, but adding
an additional layer which may be used but never gets in the way.

-ak
 
S

Seebs

To me, the problem with C ternary is, why is true condition first and
false second? It could just as well be the other way around.

Again, look at the long-form "if/else" above; it's always "if a then b
otherwise c".
With if and
else, the meaning is direct, x if y else z, or if y: x; else: z.

The latter still has condition, true, false.
That's absolutely not how I read code. For example, if you have a line
like:
x = x + 1 ASF!@#$!@$ASFASF!@#$!@$#ADFASDF!@#
Do you read it as "ok, assignment.. x is x + 1.. whoa, what the hell is
this?".

Not for something that big and visible. But the if/else stuff is
just ordinary blocks of text.
That's where syntax highlighting comes in, as well.

So basically, if we use syntax highlighting to make up for the legibility
problems of a given syntax, then the syntax is okay, but people who don't
use syntax highlighting to make up for its legibility problems are wrong.

I see.

This does seem self-contained; you like syntax highlighting because you
like constructs which are hard to read without it. You like those constructs
because they let you show off syntax highlighting.
After some time getting used to it, I'd end up seeing this as:
.
.
.
if .. else:
.
.
.
at first and then processing everything else.

Assuming that the if/else was on the same page. :)
Again, syntax highlighting
would help here. The only issue is that it'd be hard to separate the
beginning from other code, for me that'd be the primary reason why this
is not a good construct.

No matter how long I'd been using that construct, I'd still have the
problem that, mechanically, I'm going to see the opening few lines
first, and that means that those lines are going to get parsed first.

I read largely in order. I do have some lookahead, but no matter how
much I use the lookahead, I'm already parsing the first things I see,
and that's top-down-left-right.

-s
 
A

AK

Again, look at the long-form "if/else" above; it's always "if a then b
otherwise c".

Because that's what 'if' and 'else' mean. I have no problem with '?'
separating condition from possible outcomes.. The most natural reading
of that construct is that depending on condition, there are two possible
outcomes, separated by a ':' and you have to remember that first outcome
corresponds to true condition. x = y if a else z is much more pythonic
because 'else' is explicitly saying what happens on false condition.
Explicit is better than implicit.
Not for something that big and visible. But the if/else stuff is
just ordinary blocks of text.

Not with syntax highlighting they're not ;) Seriously though, my guess
is even without syntax highlighting I'd still prefer it because I do
enough look-ahead and in 95% of cases the first 'if' is close enough to
the beginning of the line. In fact, most often plain assignments will be
much shorter than this construct so you can figure it out by combination
of line length and the 'if' keyword.

It still has the advantage over the more verbose version that I
mentioned before: you can see immediately that there's an assignment to
a single variable, and the logic flows like a single sentence in a
natural language.
So basically, if we use syntax highlighting to make up for the legibility
problems of a given syntax, then the syntax is okay, but people who don't
use syntax highlighting to make up for its legibility problems are wrong.

That's not really true, it merely makes a given syntax easier to read
even when it's already a preferable syntax. It's like this, if someone
gives you five dollars for nothing, and then later gives you three
dollars, you don't complain that the latter amount is less than former :).
I see.

This does seem self-contained; you like syntax highlighting because you
like constructs which are hard to read without it. You like those constructs
because they let you show off syntax highlighting.

Well, you're exaggerating this out of all proportion just to prove a
point. I like syntax highlighting in all of python and, in fact, in all
languages I've used. Even in crontab files! This is a single construct I
can think of, which, being already very readable, explicit, and
succinct, *on top of that*, gains even more in readability due to syntax
highlight.

So, as you can see, I'd like syntax highlight just fine if this
construct was not present in Python, and in fact I did. Conversely, I'd
prefer it to the longer version if there was no syntax highlight at all.
Assuming that the if/else was on the same page. :)

I'll concede you one point in this case: if the statement 'x = .. if ..
else .. ' is split over two pages, I would at least seriously consider
the 'if: .. else: ' version. ;)

-ak
 
S

Seebs

Because that's what 'if' and 'else' mean.

My point is, I don't want the order of the clauses in if/else to change.
If it is sometimes "if <condition> <true-clause> else <false-clause>", then
it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause,
then false clause. If it's sometimes "if condition true-clause else
false-clause", and sometimes "true-clause if condition else false-clause",
that's a source of extra complexity.
I have no problem with '?'
separating condition from possible outcomes.. The most natural reading
of that construct is that depending on condition, there are two possible
outcomes, separated by a ':' and you have to remember that first outcome
corresponds to true condition.

Exactly as it ALWAYS does. That's the point.
x = y if a else z is much more pythonic
because 'else' is explicitly saying what happens on false condition.
Explicit is better than implicit.

Is it "more pythonic" to shuffle the orders of clauses in precisely
analagous constructs?

I'm not arguing against the use of the *words* "if" and "else". I'm
arguing that the shuffling of the orders of the clauses creates
confusion.
It still has the advantage over the more verbose version that I
mentioned before: you can see immediately that there's an assignment to
a single variable, and the logic flows like a single sentence in a
natural language.

I'm getting frustrated here because I really felt my point was pretty
clearly expressed, and yet, every time you respond, you respond to things
TOTALLY DIFFERENT from what I am saying.

The syntax I like for this kind of thing is:
x = if condition then true-clause else false-clause

This is because it follows the same *ordering* as the multi-line if/else,
so it preserves the logical flow. Condition, then true clause, then
false clause. Always.

The only way in which this is more verbose than the inverted one is the
"then", and you don't even need that if you stick with a python-style
colon:
x = if condition: true-clause else false-clause

But this is *always* easier to follow because it follows the same logical
structure.

Leave poetic inversion to the poets.
That's not really true, it merely makes a given syntax easier to read
even when it's already a preferable syntax.

Except that it's *NOT PREFERABLE* to me, because it is BACKWARDS.

Have I somehow failed to express this? Is there some magical rule that
it is not pythonic for you to react in any way to the actual comparison
I'm making, rather than to totally unrelated comparisons?

I gave the example of what an if/else statement looks like, not because
I think it is always better to use statements and blocks instead of
expressions, but to point out the LOGICAL ORDER. You were asking why
I preferred the condition to come first. My answer is, because the
condition comes first in an if/else statement normally, and I like to
preserve the logical flow. Instead, you're off ranting about how that's
too long.

But that's not my point. My point was *only* that the logical flow
is consistent between if/else and the way various languages have done
if/else expressions: Condition first, then true clause, then false
clause. Doesn't matter whether it's ruby or C or lua or even bourne
shell, in every other language I use that lets me use an if/else as
part of an expression, it follows the SAME logical flow as the regular
if/else statement. In Python, it's inverted.

You were arguing that this inversion is better and more intuitive,
and that there is no reason to expect the condition to come first.
But there is! The condition comes first in regular if/else statements.
This establishes a pattern -- if/else things are introduced by
their condition, then you get the true clause and then you get the
false clause.
Well, you're exaggerating this out of all proportion just to prove a
point.

No, I'm not.
This is a single construct I
can think of, which, being already very readable, explicit, and
succinct, *on top of that*, gains even more in readability due to syntax
highlight.

But it's *not readable to me*. Because it's backwards.
So, as you can see, I'd like syntax highlight just fine if this
construct was not present in Python, and in fact I did. Conversely, I'd
prefer it to the longer version if there was no syntax highlight at all.

And again, NO ONE HAS SUGGESTED THE LONGER VERSION. AT ALL. EVER. I
don't understand why you keep contrasting this with the longer version
when the only reason that was brought up was to COMPARE it in terms of
*logical flow*.

I pointed out the *PARALLELS* between conditional expressions and
conditional statements. I did not suggest that the longer version should
be preferred in all cases, or even in all that many.
I'll concede you one point in this case: if the statement 'x = .. if ..
else .. ' is split over two pages, I would at least seriously consider
the 'if: .. else: ' version. ;)

Okay, one more time:

I am not proposing the use of multi-line statements as superior to
conditional expressions. I am *ONLY* stating that I find the
"true-clause if condition else false-clause" form confusing because it
inverts the LOGICAL FLOW of multi-line if/else statements.

By the nature of programming, I'm going to have to use if/else statements
a lot. So I'm going to be used to the way they flow -- condition,
true, false. Condition, true, false. Condition, true, false. It goes
in that order every time, in every language I use, both when working
with statements and when working with expressions. EXCEPT. That in
one specific language, when doing expressions (but not statements),
it is "True, condition, false."

That's all I'm talking about. I am not arguing whether conditional
expressions are better or worse than conditional statements. I am not
arguing whether conditional expressions should exist at all. I am
only pointing out that I find it much clearer when conditional expressions
follow the same pattern as other conditional things.

Condition, true, false.

Is there something horribly unusual about wanting to take advantage of
the fact that my brain has a much easier time processing things when they
follow consistent patterns?

-s
 
M

MRAB

My point is, I don't want the order of the clauses in if/else to change.
If it is sometimes "if<condition> <true-clause> else<false-clause>", then
it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause,
then false clause. If it's sometimes "if condition true-clause else
false-clause", and sometimes "true-clause if condition else false-clause",
that's a source of extra complexity.
[snip]
Have you read PEP 308? There was a lot of discussion about it.
 
G

Gregory Ewing

AK said:
Afaik the idea is that you can read a novel at the speed of half a page
a second or so and understand it to the same extent as people who'd read
at a normal rate.

I've never understood why anyone would *want* to read a
novel that fast, though. For me at least, reading a novel
is something done for pleasure, so reading it at ten times
normal speed would waste 90% of the benefit.
 
S

Seebs

My point is, I don't want the order of the clauses in if/else to change.
If it is sometimes "if<condition> <true-clause> else<false-clause>", then
it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause,
then false clause. If it's sometimes "if condition true-clause else
false-clause", and sometimes "true-clause if condition else false-clause",
that's a source of extra complexity.

[snip]
Have you read PEP 308? There was a lot of discussion about it.

Interesting, in the historical section we see:

The original version of this PEP proposed the following syntax:

<expression1> if <condition> else <expression2>

The out-of-order arrangement was found to be too uncomfortable
for many of participants in the discussion; especially when
<expression1> is long, it's easy to miss the conditional while
skimming.

But apparently those objections were either unknown or disregarded when
the syntax was later adopted.

-s
 
S

Seebs

I've never understood why anyone would *want* to read a
novel that fast, though. For me at least, reading a novel
is something done for pleasure, so reading it at ten times
normal speed would waste 90% of the benefit.

I get pleasure from the story, not from the time spent. Reading faster
means I get more stories. Same thing, to some extent, with programming.
I could easily spend much more time writing some programs by switching
to a language ill-suited to them (say, using C for heavy string
manipulation, or PHP for anything), but that wouldn't mean I had more fun,
it would mean my fun was spread out over a longer period of time, and might
well cross over to no-longer-fun.

-s
 
A

alex23

AK said:
When I was reading The book of the new sun, though, I could stop and
read a single sentence a few times over and reflect on it for a minute.

Totally understandable, Wolfe is a far, far greater writer than
Rowling :)
 
A

AK

I've never understood why anyone would *want* to read a
novel that fast, though. For me at least, reading a novel
is something done for pleasure, so reading it at ten times
normal speed would waste 90% of the benefit.

One definite advantage would be that if, say, it takes you 70 pages of a
given novel to figure out whether you like it enough to continue, you'd
want to read those pages in 2 minutes rather than an hour.
Unfortunately, beginning of a novel is where I have to read at the
slowest rate because I'm not used to author's style and pacing yet
and I don't want to miss something crucial.

-ak
 
S

Seebs

Totally understandable, Wolfe is a far, far greater writer than
Rowling :)

Certainly true. On the other hand, I found it frustrating when I *had*
to re-read a passage a couple of times to figure out what had just
happened. :) ... Not that rereading books is necessarily a bad thing.

-s
 
J

John Bokma

AK said:
One definite advantage would be that if, say, it takes you 70 pages of a
given novel to figure out whether you like it enough to continue, you'd
want to read those pages in 2 minutes rather than an hour.

Heh, to me speed reading those 70 pages in a very short while,
concluding that it's a good book, and start over again would be quite
the spoiler. Do you fast forward movies as well?

I do speed read but not the books I read for pleasure.
 
S

Seebs

Heh, to me speed reading those 70 pages in a very short while,
concluding that it's a good book, and start over again would be quite
the spoiler.

I rarely encounter substantive spoilers in the first 70 pages or so of
a book. That said, I'm pretty much immune to spoilers; while I'm reading,
I'm usually ignoring anything I might have previously known about a
story, so it all works even if I've read it before.
Do you fast forward movies as well?

Amusingly, I can't generally watch movies at normal speed. They're
too boring. Luckily, computers are finally advancing to a point where
"1.2x faster, but no chipmunks" is an available setting in some
software.

-s
 
S

Steven D'Aprano

I've never understood why anyone would *want* to read a novel that fast,
though. For me at least, reading a novel is something done for pleasure,
so reading it at ten times normal speed would waste 90% of the benefit.

Or reduce the pain by 90%, depending on the book...
 
S

Seebs

I didn't mean that there are spoilers in the first 70 pages, just that
to me the excercise would spoil the book, so, I wouldn't do it. I
consider a book like a meal, I wouldn't gobble down food, regurgitate
it, and eat it again at a slower pace. Books, movies, family, walks are
the things I prefer to do at a normal mudane pace, or even slower, if I
can bring myself to it. My favourite books I try to read slow, and
enjoy. ;-). Too much of my life is already in overdrive.

Now that you explain it like this, that makes a fair bit of sense. I
often wonder whether reading slowly would be more pleasant. I have no
idea how to do it, so the question remains theoretical.

-s
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,599
Members
45,175
Latest member
Vinay Kumar_ Nevatia
Top