3 ms·

Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.

by arpa 7y ago

jerf 7y ago
Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accidentally. I've actually noticed one thing about Common Core is that they do try much harder than when I was a kid to not accidentally create that impression; my kid's homework is full of "4 + 3 = ___" followed immediately by "____ = 8 + 2". Still kind of glossing over "=" as a "simplify" operator, but it's still an improvement over when I was a kid when it was really easy to pick up the idea that the "=" operator was actually a function meaning "take the expression on the left and simplify it". (I mean, there's a sense where such students aren't even wrong; it is the rational conclusion from the evidence presented.)
- AllegedAlec 7y ago
  > Still kind of glossing over "=" as a "simplify" operator, but it's still an improvement over when I was a kid when it was really easy to pick up the idea that the "=" operator was actually a function meaning "take the expression on the left and simplify it". What? No. De '=' sign is very simple: what's written to the left of it is equal to what's written on its right.
  - bregma 7y ago
    The takeaway that many students have is that the equals sign if equivalent to the -> sign, which definitely implies simplification. I know I was set straight as a university freshman in the 1980s, and I have read many things since about that same confusion. Outside of math it probably doesn't matter. Inside of math it matters a lot. Programming is math.
    - jerf 7y ago
      I just want to confirm this is what I meant. While I wasn't as badly affected as some of my peers, I still remember when I truly realized what equality meant. That occurred in college, and embarrassingly late in college at that (though it was in undergrad at least). I suspect I got some extra cognitive interference from my programming language experience, so non-programmers would hopefully have an easier time of it. And I was solving systems of equations with substitution and doing all the usual things to equations one does in math classes, and to all external appearances I would have looked like I understood equality prior to that. But I didn't. Not fully. In hindsight, the best evidence of this was in physics class, where I was perfectly adequate at taking the provided equations and using them, and I understood their derivation, but I still wasn't all that great at combining them fluidly; F = ma, yes, but it still didn't quite fully register that that meant anywhere I saw an F, in any other equation in which it appeared, I could drop in an ma. It's not that F is "convertable" to ma, or that ma simplifies to F, or that the name of ma is F... it's that they ARE each other, there is no conceivable way you can separate them, there is no conceivably witnessable in any way, mathematically or practically, effect from substituting one for the other, there is only one entity that can be named in various ways. I did not fluidly combine them the way I should. If I had the class to do over again, I would do way better this time, even we could somehow erase my first pass entirely from my mind.
- ninkendo 7y ago
  > If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator Code is for humans, not computers. The order I choose when writing an expression is driven by what I want to convey to the next person reading my code. `if (button.state == .enabled)` suggests to the reader that the button’s state is the thing we’re interested in in this particular piece of code. Reversing the operands is confusing not because I don’t understand the communicative property, it’s confusing because it puts the emphasis on the wrong thing: I’m not checking if the enabled state matches an expectation, I’m checking if the button’s state matches an expectation. And I want the reader to understand that.
  - deleted 7y ago
    [deleted]
- jameshart 7y ago
  There are two perfectly valid ways of reading x == y aloud as an English statement: > X equals Y > X and Y are equal The first sentence uses active voice - the second passive. Active voice ascribes agency to X; It makes a subject/object distinction between X and Y. Passive voice makes them both objects. When reading code, it makes more sense to ascribe agency to variables than to constants, which is why people are more comfortable reading x == 0 than 0 == x. Zero can’t change, so it can’t do anything to make itself equal something. X can change, so it is capable of equaling things. If you’re equally comfortable with either formulation, maybe you just prefer the passive reading of the sentence. But I do wonder if you’d be equally happy if I went through your codebase and replaced every for loop condition from i < length to length > i...
  - jerf 7y ago
    This is exactly the point I'm making; if we must ascribe agency at all (I'm thinking that's a category error here, but human thought is fuzzy and I'll roll with it for now), it would belong to the "==". Don't read it as English at all; read it natively. There is a reason we call these programming languages, no joke, no pun. "But I do wonder if you’d be equally happy if I went through your codebase and replaced every for loop condition from i < length to length > i..." You'd have a hard time of it; I'm a vigorous believer in doing whatever you can in the language you're in to avoid the old 3-element-style C-style for loops in favor of "for ... in ..." or local equivalent. I'm pretty sure you'd get single digit hits for C-style for loops with multiple clauses in the condition.
  - deleted 7y ago
    [deleted]
- mrkeen 7y ago
  I don't have a problem with 'equals' being commutative. My programming language does.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
flanbiscuit 7y ago
Haha it took me a second to realize what you did there
- jonny_eh 7y ago
  A second to realize what you did there it took me.

Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.

by arpa 7y ago

Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.

jerf 7y ago

Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accidentally. I've actually noticed one thing about Common Core is that they do try much harder than when I was a kid to not accidentally create that impression; my kid's homework is full of "4 + 3 = ___" followed immediately by "____ = 8 + 2". Still kind of glossing over "=" as a "simplify" operator, but it's still an improvement over when I was a kid when it was really easy to pick up the idea that the "=" operator was actually a function meaning "take the expression on the left and simplify it". (I mean, there's a sense where such students aren't even wrong; it is the rational conclusion from the evidence presented.)

AllegedAlec 7y ago
> Still kind of glossing over "=" as a "simplify" operator, but it's still an improvement over when I was a kid when it was really easy to pick up the idea that the "=" operator was actually a function meaning "take the expression on the left and simplify it". What? No. De '=' sign is very simple: what's written to the left of it is equal to what's written on its right.
- bregma 7y ago
  The takeaway that many students have is that the equals sign if equivalent to the -> sign, which definitely implies simplification. I know I was set straight as a university freshman in the 1980s, and I have read many things since about that same confusion. Outside of math it probably doesn't matter. Inside of math it matters a lot. Programming is math.
  - jerf 7y ago
    I just want to confirm this is what I meant. While I wasn't as badly affected as some of my peers, I still remember when I truly realized what equality meant. That occurred in college, and embarrassingly late in college at that (though it was in undergrad at least). I suspect I got some extra cognitive interference from my programming language experience, so non-programmers would hopefully have an easier time of it. And I was solving systems of equations with substitution and doing all the usual things to equations one does in math classes, and to all external appearances I would have looked like I understood equality prior to that. But I didn't. Not fully. In hindsight, the best evidence of this was in physics class, where I was perfectly adequate at taking the provided equations and using them, and I understood their derivation, but I still wasn't all that great at combining them fluidly; F = ma, yes, but it still didn't quite fully register that that meant anywhere I saw an F, in any other equation in which it appeared, I could drop in an ma. It's not that F is "convertable" to ma, or that ma simplifies to F, or that the name of ma is F... it's that they ARE each other, there is no conceivable way you can separate them, there is no conceivably witnessable in any way, mathematically or practically, effect from substituting one for the other, there is only one entity that can be named in various ways. I did not fluidly combine them the way I should. If I had the class to do over again, I would do way better this time, even we could somehow erase my first pass entirely from my mind.
ninkendo 7y ago
> If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator Code is for humans, not computers. The order I choose when writing an expression is driven by what I want to convey to the next person reading my code. `if (button.state == .enabled)` suggests to the reader that the button’s state is the thing we’re interested in in this particular piece of code. Reversing the operands is confusing not because I don’t understand the communicative property, it’s confusing because it puts the emphasis on the wrong thing: I’m not checking if the enabled state matches an expectation, I’m checking if the button’s state matches an expectation. And I want the reader to understand that.
- deleted 7y ago
  [deleted]
jameshart 7y ago
There are two perfectly valid ways of reading x == y aloud as an English statement: > X equals Y > X and Y are equal The first sentence uses active voice - the second passive. Active voice ascribes agency to X; It makes a subject/object distinction between X and Y. Passive voice makes them both objects. When reading code, it makes more sense to ascribe agency to variables than to constants, which is why people are more comfortable reading x == 0 than 0 == x. Zero can’t change, so it can’t do anything to make itself equal something. X can change, so it is capable of equaling things. If you’re equally comfortable with either formulation, maybe you just prefer the passive reading of the sentence. But I do wonder if you’d be equally happy if I went through your codebase and replaced every for loop condition from i < length to length > i...
- jerf 7y ago
  This is exactly the point I'm making; if we must ascribe agency at all (I'm thinking that's a category error here, but human thought is fuzzy and I'll roll with it for now), it would belong to the "==". Don't read it as English at all; read it natively. There is a reason we call these programming languages, no joke, no pun. "But I do wonder if you’d be equally happy if I went through your codebase and replaced every for loop condition from i < length to length > i..." You'd have a hard time of it; I'm a vigorous believer in doing whatever you can in the language you're in to avoid the old 3-element-style C-style for loops in favor of "for ... in ..." or local equivalent. I'm pretty sure you'd get single digit hits for C-style for loops with multiple clauses in the condition.
- deleted 7y ago
  [deleted]
mrkeen 7y ago
I don't have a problem with 'equals' being commutative. My programming language does.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]

flanbiscuit 7y ago

Haha it took me a second to realize what you did there

jonny_eh 7y ago
A second to realize what you did there it took me.