4 ms·

It's... the modulo operator

jbverschoor 4y ago
Yes. But you’re not expressing what you mean. You don’t want the remainder. It’s like doing a for(i=0; i<items.length:i++) { e=items[i] } to iterate over each element instead of something like foreach, or a lambda.
- haswell 4y ago
  Of all the possible examples to choose, I would not have guessed a classic for/each would be at issue. How is that for loop not expressing what it means? for is used to iterate over something. There are legitimate reasons to choose for even when forEach is available. Does this not express what I mean? if (amount > balance) return “insufficient_funds”; Chances are, I’ll put this in a method anyway, and that’s what a language enables me to do - to create meaning that is contextual to my program. Abstraction can help simplify complex problems, and that’s what it is good at. But when literally everything is abstracted away, it becomes harder to reason about what the program is doing without also learning about what the particular abstraction does (e.g. implicitly handling negative numbers, etc). A well implemented standard library can be a joy to use, and some people choose languages for this reason. Some languages very intentionally provide a very lightweight standard library, and that’s just fine. All of this shouldn’t absolve the developer from understanding some of the very basic constructs of the language they choose - a lack of which will lead to bugs and vulnerabilities. If I choose JavaScript (or it’s chosen for me), it behooves me to understand the basics vs. farming this out to some node package that just made my app harder to reason about and vulnerable to supply chain attacks for essentially no value.
  - ColinWright 4y ago
    I don't usually get drawn into this, but I have an answer to this because I've seen something similar in production. jbverschoor said (edited for brevity): > Yes. But you’re not expressing what you mean. > It’s like doing a > for(i=0; i<items.length:i++) > { e=items[i] } > to iterate over each element instead of something like foreach ... haswell replied: > How is that for loop not expressing what it means? It's true that the for loop is accomplishing the goal, but it is specifically running through the elements from 0 to length. But sometimes what you want to do is, for example, apply a function to every element, and the fact that they are in a structure indexed from 0 to N-1 is not relevant. Your intent is to do a thing for every element, not to run down a list doing the thing. There is a difference in intent, and using foreach instead of a for loop quite specifically expresses that. Small examples like this are never convincing, but there really is a difference between "Run down this list" and "do this thing for every element". The output is the same, but the intent is different, and expressing that intent is important in larger projects.
    - haswell 4y ago
      That intent is implicit, and using for or forEach does not by itself provide enough information about intent. I agree that using one vs. the other can be a strong hint. The surrounding code provides the rest of the story. It may be true that running from 0…length is not the most important part, but it may also be true that I need more flexibility and control while iterating, and may still choose to use for as a result. But I think we’re getting a bit off track (and I helped get us here…). jbverschoor‘s comment was a followup about the expressiveness of the modulo operator vs built-in convenience methods. At least in the case of JavaScript, there isn’t an isEven available. If it was, an argument could be made that using it is more expressive. Since it doesn’t, the argument can be made that the most expressive option is the idiomatic one. Certain code fragments become idiomatic for a reason. I interpreted the comments about for and the perceived lack of expressiveness in using it against this backdrop, and my point was just that for still has a time and a place. It may be that jbverschoor recognizes this, but I think the comparison doesn’t quite help when examining the use of modulo.
      - ColinWright 4y ago
        I suspect we are largely in agreement. The example is not necessarily a good one, but I think we agree that the intent expressed by "foreach" is different from the intent expressed by "for ()", and while that difference might not matter, and might not be large, and might be carried equally by the context, it is real. Going back to the original, there is a difference between "isEven(n)" and "0==n%2". Sometimes (and this is definitely true in some code I write) there is a conceptual difference between asking if something is even, versus asking if it leaves a remainder of 0 upon division by 2. Yes, they can be proven to be equivalent, but the underlying intent is different. BTW, I agree entirely that in these cases it's really mostly pointless, but the principle carries over to larger examples. Trying to see that there is a difference is probably worth it, even if we agree that it doesn't really matter in these trivial cases. Oh, and for a compiler I used to use it really did matter that you used "foreach" when you could, versus using "for ()", because it could dispatch things in parallel in the former case, and couldn't in the latter. So expressing the intent in the code itself and not just in the context really can matter.

Yes. But you’re not expressing what you mean. You don’t want the remainder. It’s like doing a for(i=0; i<items.length:i++) { e=items[i] } to iterate over each element instead of something like foreach, or a lambda.

haswell 4y ago
Of all the possible examples to choose, I would not have guessed a classic for/each would be at issue. How is that for loop not expressing what it means? for is used to iterate over something. There are legitimate reasons to choose for even when forEach is available. Does this not express what I mean? if (amount > balance) return “insufficient_funds”; Chances are, I’ll put this in a method anyway, and that’s what a language enables me to do - to create meaning that is contextual to my program. Abstraction can help simplify complex problems, and that’s what it is good at. But when literally everything is abstracted away, it becomes harder to reason about what the program is doing without also learning about what the particular abstraction does (e.g. implicitly handling negative numbers, etc). A well implemented standard library can be a joy to use, and some people choose languages for this reason. Some languages very intentionally provide a very lightweight standard library, and that’s just fine. All of this shouldn’t absolve the developer from understanding some of the very basic constructs of the language they choose - a lack of which will lead to bugs and vulnerabilities. If I choose JavaScript (or it’s chosen for me), it behooves me to understand the basics vs. farming this out to some node package that just made my app harder to reason about and vulnerable to supply chain attacks for essentially no value.
- ColinWright 4y ago
  I don't usually get drawn into this, but I have an answer to this because I've seen something similar in production. jbverschoor said (edited for brevity): > Yes. But you’re not expressing what you mean. > It’s like doing a > for(i=0; i<items.length:i++) > { e=items[i] } > to iterate over each element instead of something like foreach ... haswell replied: > How is that for loop not expressing what it means? It's true that the for loop is accomplishing the goal, but it is specifically running through the elements from 0 to length. But sometimes what you want to do is, for example, apply a function to every element, and the fact that they are in a structure indexed from 0 to N-1 is not relevant. Your intent is to do a thing for every element, not to run down a list doing the thing. There is a difference in intent, and using foreach instead of a for loop quite specifically expresses that. Small examples like this are never convincing, but there really is a difference between "Run down this list" and "do this thing for every element". The output is the same, but the intent is different, and expressing that intent is important in larger projects.
  - haswell 4y ago
    That intent is implicit, and using for or forEach does not by itself provide enough information about intent. I agree that using one vs. the other can be a strong hint. The surrounding code provides the rest of the story. It may be true that running from 0…length is not the most important part, but it may also be true that I need more flexibility and control while iterating, and may still choose to use for as a result. But I think we’re getting a bit off track (and I helped get us here…). jbverschoor‘s comment was a followup about the expressiveness of the modulo operator vs built-in convenience methods. At least in the case of JavaScript, there isn’t an isEven available. If it was, an argument could be made that using it is more expressive. Since it doesn’t, the argument can be made that the most expressive option is the idiomatic one. Certain code fragments become idiomatic for a reason. I interpreted the comments about for and the perceived lack of expressiveness in using it against this backdrop, and my point was just that for still has a time and a place. It may be that jbverschoor recognizes this, but I think the comparison doesn’t quite help when examining the use of modulo.
    - ColinWright 4y ago
      I suspect we are largely in agreement. The example is not necessarily a good one, but I think we agree that the intent expressed by "foreach" is different from the intent expressed by "for ()", and while that difference might not matter, and might not be large, and might be carried equally by the context, it is real. Going back to the original, there is a difference between "isEven(n)" and "0==n%2". Sometimes (and this is definitely true in some code I write) there is a conceptual difference between asking if something is even, versus asking if it leaves a remainder of 0 upon division by 2. Yes, they can be proven to be equivalent, but the underlying intent is different. BTW, I agree entirely that in these cases it's really mostly pointless, but the principle carries over to larger examples. Trying to see that there is a difference is probably worth it, even if we agree that it doesn't really matter in these trivial cases. Oh, and for a compiler I used to use it really did matter that you used "foreach" when you could, versus using "for ()", because it could dispatch things in parallel in the former case, and couldn't in the latter. So expressing the intent in the code itself and not just in the context really can matter.