Hacker News Reader

Comment by caseymarquis | Hacker News Reader

I immediately thought: "But no one would actually add that dependency!" Only to see 120k weekly downloads of is-even.

I... don't understand...

It's not just checking if the number is odd. It checks if the input is a number (modulus on a non-Number value returns a NaN in JS), if it's an integer (not strictly necessary I guess), and if it's within the bounds of JS's safe integer range (again, you'll get a NaN if the number is too big). If you want to make sure your code is safe those are sensible things to check.

A lot of JS devs wouldn't bother check those things, so really a lot of code is improved by this library. It's kind of a shame that so many developers just skip over checking inputs really. That's the real problem.

The obvious solution would be to have some stdlib or even a common-utils project or something like it, which contain all such items. In one package.

Because, indeed, no-one should be rewriting obvious code like isArray, leftPad, isEven and so on.

Yes, that might cause some overhead in some situations (when you need isOdd, but not leftPad). But I'm certain that overhead is minimal. In practice, however, we currently see dependency-trees where these "should-be-stdlib" modules like "leftPad" or "isArray" are repeated numerous times in one project.

Any stdlib could even be optimized by browsers and engines, turning that "overhead" into a net benefit.

It doesn't.

  isOdd('') => false
  isOdd(null) => false
  isOdd(2n) => TypeError: Cannot convert a BigInt value to a number

But even if it did, the same line of reasoning leads to the absurd conclusion we should have an addOne function.

> I... don't understand...

You are not supposed to reinvent the wheel. Somebody has already gone through the trouble of implementing the is-even algorithm, and it would be a waste of time to re-write it for no purpose. You may think that it is a simple algorithm, but I doubt you could implement it better than the people who uploaded these files to npm. Notice that the algorithm has many obscure corner-cases that you are likely to miss on your first implementation. Fortunately, it is already written and packaged; just use it.

Note that this implementation of `isEven` throws on input that isn't a number or numbers that are not integers, NaN or larger than 2^53-1. I think it's fair to argue an implementation could just as well return false for 1.4, NaN or '2'. There is a cost to learning these minutiae of your dependencies, especially if there is no compiler support to assist you.

I've not programmed a lot of JS, so this might be obvious for someone who did, but:

Why does he first use Math.abs on the parameter and then type check the result of that? I'd think if you do an argument type check, you'd do it before using it. Just to make it not throw on null? I don't see the sense in that...

I'm not sure this is the reason for that specific implementation but `Math.abs` _will_ do a string-to-number conversion.

I.e., `Math.abs("-27")` yields `27`.

It might be the case that Math.abs does other *-to-number conversions also, so maybe this method is trying to take advantage of that. (Math.abs is usually implemented as a native function so without digging more deeply it's not obvious to me what the actual implementation does.)

UPDATE: Curiously, `Math.abs(null)` yields `0`, so a null argument passed to is-even would yield `true` I guess.

Also whatever the logic is for that conversion is it is not the same as the built-in `parseInt` or `parseFloat`. `parseInt("27 meters")` yields `27` but `Math.abs("27 meters")` yields `NaN`.

Personally in JavaScript I almost universally make use of home-grown `isInt` and `toInt` methods whose behavior is predicable for me -- eg. my toInt() will reject a string that's not _just_ an integer value (and return `null` rather than `NaN` in all cases because who wants to check `isNaN`?) -- but that's probably not a great practice either. But I've been programming long enough to realize that the principle of least surprise is probably the most important concern here for long-term efficiency. I suppose what is or is not surprising may be subjective though.

</sarcasm>

I think you're getting some down votes as you missed a closing tag.

Man I hope they did (just forget the closing tag). Poe's law in action.

But if you indicate sarcasm as such, it ceases to be so! The best sarcasm is one that leaves exactly half of the people believing it to be sarcasm, and the other half agreeing with it. Otherwise, it is just a farcical exaggeration (which is also funny, but for different reasons).

For the record, 120k weekly downloads isn't really _that_ large in this ecosystem.

That's 120k instances of people or scripts doing `npm install is-even` or the equivalent.

For comparison:

* Lodash - a general purpose set of library/utility functions by the way - has ~26M weekly downloads.

* request - an HTTP client library - has ~19M weekly downloads

I wouldn't add is-even as a direct dependency either, but I think people are underestimating the size and diversity of the JavaScript ecosystem as a whole.

Reply on news.ycombinator.com