5 ms·

>I don't fully understand why packages like this are so popular. I consider 'iseven' and 'isodd' to be signs that Javascript is a hellaciously engineered piece

by aa-jv 4y ago

>I don't fully understand why packages like this are so popular. I consider 'iseven' and 'isodd' to be signs that Javascript is a hellaciously engineered piece of crap that should be avoided at all costs. They're popular because Javascript is garbage.

haswell 4y ago
JavaScript supports the modulo operator and the native syntax for this: let isEven = theNumber % 2 == 0; There are reasons to dislike JavaScript, but this isn’t it. The native solution is about as standard as it gets.
- jbverschoor 4y ago
  You’re not expressing what you mean by %.. I’m all against these packages, but in Ruby we have a good standard library.
  - krembanan 4y ago
    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.
  - haswell 4y ago
    I’m a big fan of Ruby and yes, Ruby handles this elegantly. However, some variation on n%2==0 is idiomatic in a large number of languages, both modern and old [0]. This includes Lua, Java, Python, Scala, Perl, PHP, Swift, and many others. It is true that there are numerous languages with built in convenience methods in their standard libraries, but that does not by itself mean that n%2==0 is problematic and certainly this idiom is deeply entrenched. There is nothing preventing a developer using those languages from wrapping this in a function, and indeed this is probably a good idea if it’s something you find yourself using repeatedly throughout your code base, just like any other often-repeated code snippets. - [0] https://www.rosettacode.org/wiki/Even_or_odd https://www.rosettacode.org/wiki/Even_or_odd
- russtrotter 4y ago
  The old C bum in me says this should really be a bitwise AND with 1 but I'm sure modern compilers and JS JIT/V8 runtimes optimize MOD 2 to the same.
  - repiret 4y ago
    I spend most of my time writing C for embedded systems. You should focus first on making life easy for the people reading your code. Use `% 2` and `* 4` when those are the things you mean, rather than `& 1` and `<< 2`. Compilers have been able to do those strength reductions on their own for years, and in most cases even if the compiler didn't, the cycles you'd save aren't worth it.
- aa-jv 4y ago
  Please explain to me why there is a package "iseven" and "isodd" if not for the fact that some Javascript kiddy was unable to work this out for themselves by applying the intrinsics of the language, standardly .. Because I firmly believe that crap like this happens because the language itself is very, very dumb.

by aa-jv 4y ago

haswell 4y ago

JavaScript supports the modulo operator and the native syntax for this: let isEven = theNumber % 2 == 0; There are reasons to dislike JavaScript, but this isn’t it. The native solution is about as standard as it gets.

jbverschoor 4y ago
You’re not expressing what you mean by %.. I’m all against these packages, but in Ruby we have a good standard library.
- krembanan 4y ago
  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.
- haswell 4y ago
  I’m a big fan of Ruby and yes, Ruby handles this elegantly. However, some variation on n%2==0 is idiomatic in a large number of languages, both modern and old [0]. This includes Lua, Java, Python, Scala, Perl, PHP, Swift, and many others. It is true that there are numerous languages with built in convenience methods in their standard libraries, but that does not by itself mean that n%2==0 is problematic and certainly this idiom is deeply entrenched. There is nothing preventing a developer using those languages from wrapping this in a function, and indeed this is probably a good idea if it’s something you find yourself using repeatedly throughout your code base, just like any other often-repeated code snippets. - [0] https://www.rosettacode.org/wiki/Even_or_odd https://www.rosettacode.org/wiki/Even_or_odd
russtrotter 4y ago
The old C bum in me says this should really be a bitwise AND with 1 but I'm sure modern compilers and JS JIT/V8 runtimes optimize MOD 2 to the same.
- repiret 4y ago
  I spend most of my time writing C for embedded systems. You should focus first on making life easy for the people reading your code. Use `% 2` and `* 4` when those are the things you mean, rather than `& 1` and `<< 2`. Compilers have been able to do those strength reductions on their own for years, and in most cases even if the compiler didn't, the cycles you'd save aren't worth it.
aa-jv 4y ago
Please explain to me why there is a package "iseven" and "isodd" if not for the fact that some Javascript kiddy was unable to work this out for themselves by applying the intrinsics of the language, standardly .. Because I firmly believe that crap like this happens because the language itself is very, very dumb.