too be honest, a comment of someone doesn't make it true. It could be he has actual use cases for these repositories. Just that someone thinks it should'nt be used like this, doesn't mean it's true.
It seems like a lot of people think they think how npm should work, while forgetting to see how npm actually works.
There's even an example of a well respected npm author that has repositories with just a few lines..
The "joke" is that you can determime whether a number is odd or even with a modulo in half the code and a fraction of the storage space of a library. There is no use case for it because it's a built-in feature of the language, and in the age of inane web bloat, supply chain attacks and Javascript cargo-culting, I think laughing at stuff like this is perfectly warranted.
JavaScript does have bitwise operators. Something I was surprised by was that numbers are stored as 64 bit while all of the bitwise operators operate on 32 but numbers. This means that every operation results in a number conversion first.
Not just 64 bit. 64 bit floating point. You can't just get the "low bit". You need to take the exponent into account to figure out which bit of the mantissa to grab. It's intrinsically more computationally difficult than is-odd on a real integer.
> It could be he has actual use cases for these repositories.
If that were true, it would be useful for the author to actually explain that in his repo documentation. As it is, concluding that this is a joke is by far the most reasonable response.
Ok, which programming languages actually have an isOdd or an isEven function in their standard library?
Anyway, Javascript, like virtually every programming language, has "& 1".
Yes, the standard library is lacking and yes, that's a big issue, partly responsible for the huge mess that is NPM. No, it does not matter one bit here so this is off topic.
I don't get the issue. You write a function to check if a number is odd. You seem to have this function in every project so you make a package for it so you, and others, can easily include it. This is exactly what npm is made for?
Testing whether a number is odd is done in 3 characters:
n % 2
if you don't like the % you can also do it using a bitwise AND, this also handles negative numbers:
n & 1
this is equal to 1 if the number is odd, 0 if it is even, and will be converted to true or false in a if statement. You don't need a library for this.
And you should not need a library to handle string conversions, you should be aware of the types you manipulates. If you do need to handle strings, that's still easy:
Number(n) & 1
And Number(n) is a no op if n is already a number. But wait, no, actually, you don't even need this because % and & will auto cast the string to a number anyway. You can use parseInt(n) if there's a chance that your number is going to be non integer, but meh.
So n & 1 will cover everything.
All this is readable and idiomatic, there's no need to write a function for that, let alone a full fledged library with unit tests, package.json and all this crap that bloats the node_module folders of everybody.
isOdd = require('isOdd') and your entry in the dependencies of your package.json is going to be more verbose than isOdd = n => n & 1. Even "isOdd(n)" is longer than "n & 1". Nothing beats the "& 1".
If people are going to write libraries for all kind of similarly small and trivial things, soon we will need more than the Earth to handle our code.
Before reading your comment, I probably would have agreed with you that isOdd was overkill.
After reading your comment, I'm starting to think that isOdd is not only more readable but safer. I don't think I ever thought about n % 2 not handling negative numbers, and I'm not sure I would immediately recognize n & 1 as equivalent to isOdd. In languages without truthiness, n % 2 == 0 is longer than isOdd(n). Likewise, even with truthiness, n % 2 == 1 is longer than isEven(n).
I suspect that the real problem is the cost of adding dependencies, in terms of package size, performance, and security. All these problems could be solved using linking, inlining, and auditing.
But would you be sure that the implementation isOdd you are using is safe? To be sure you end up needing to try a few values, or to read the implementation, at which point you might as well write isOdd = n => n % 1.
That does not hold true for more complex stuff, but to test whether a number is odd, come on.
You'll test your code if it works anyway and if your odd test is wrong it will show.
But yes, you need to make sure on how '%' works in your programming language especially on negative numbers (and on non integers) because that can differ.
If you are testing whether a number is odd and that number can be negative, you'll probably think about it anyway.
That's a trap you should encounter once and then you are good.
You don't have to tell me how to calculate if a number is odd or even, that's not my point.
The thing is, n % 2, i need to do mental gymnastics do comprehend whats going on. Even if your function is just one line, I rather read isOdd or isEven instead of n % 1 of n % 2, remembering when 1 or 2 stand for even or odd is something I could have trouble with.
Telling you how to do it was not actually my point too, sorry if it sounded patronizing, that was not the intention. I was writing this for all the readers here, starting from the beginning for completeness' sake, at the risk of stating the obvious.
n % 2 or n & 1 is something you likely get used to if you encounter it frequently enough, and at least something you should recognize after the first time you encounter it. And most people should have encountered it at least once because that's one of the things we learn to do when learning programming (but I guess Ten Thousand [1] can apply). If you don't encounter it enough to be used to it, then the rare gymnastic should not be a big issue neither. You need to be able to recognize it because it's in the wild.
If having an isOdd or isEven function around makes the code more readable for you anyway it's fine, especially if the function can be inlined, but pulling an external dependency for this is overkill.
The issue is the idea of introducing an external dependency for a one line function that anyone with a rudimentary understanding of programming should be able to write in their sleep. The idea of sharing code isn't flawed here, but the risk / reward in these cases is very much out of whack.
The risk / reward of using npm is always there. It doesn't matter how big the package is. Any dependency is a risk? You're free to not use the dependency. Nobody is forcing you.
If someone wants a 1 line dependency, I say let them. I have zero issues with that.
Again, if you think something is not how it supposed to be, maybe YOUR view on what it supposed to do is whack instead?
How far do you take this: an `inc()` function? If we get to a stage where every piece of software in the world depends on one random person's ridiculous npm module, we'll be in a pretty precarious state.
[1]: https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even