[dncornholio]

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?

[jraph]

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.

[miguelrochefort]

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.

[jraph]

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.

[dncornholio]

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.

[jraph]

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.

[1] https://xkcd.com/1053/

[dncornholio]

> if you encounter it frequently enough

That's a huge if!

So abstracting a one line in a function is actually good. Putting it up on npm is debatable.

[__del__]

those poor gymnasts do some truly impressive things, and then every little leap of basic thought is conflated with their work

[dncornholio]

well said :) sad but true

[zeta0134]

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.

[dncornholio]

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?

[oneeyedpigeon]

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.