3 ms·

Kinda funny such a package exists. I was looking at the source and to be fair the author states "I created this in 2014, when I was learning how to program.". T

by wsc981 6y ago

Kinda funny such a package exists. I was looking at the source and to be fair the author states "I created this in 2014, when I was learning how to program.". The project is archived. Anyways, source seems to be as such: 'use strict'; var isOdd = require('is-odd'); module.exports = function isEven(i) { return !isOdd(i); }; Then we look as the is-odd package and we see the following: 'use strict'; const isNumber = require('is-number'); module.exports = function isOdd(value) { const n = Math.abs(value); if (!isNumber(n)) { throw new TypeError('expected a number'); } if (!Number.isInteger(n)) { throw new Error('expected an integer'); } if (!Number.isSafeInteger(n)) { throw new Error('value exceeds maximum safe integer'); } return (n % 2) === 1; }; It's kinda sad that JavaScript needs so many lines of code to figure out if a number is even, but understandable due to its dynamic nature. Not even sure how many lines the is-number package contains, but I'm guessing it's more than 2. And who knows, perhaps is-number has other dependencies? I'm no web dev, but I feel it'd be nice if there was some modern, statically typed language integrated into every browser that would be a viable replacement of JavaScript.

krapp 6y ago
>It's kinda sad that JavaScript needs so many lines of code to figure out if a number is even, but understandable due to its dynamic nature It doesn't. Javascript doesn't need this many lines of code to figure out if a number is even. A simple modulo 2 check works just fine.
- wsc981 6y ago
  Ah, so I guess it's just some over-engineered piece of code. Again I'm no web dev, so very limited JavaScript experience. Well, at least the author made it clear it was code from back when he was still learning JavaScript.
  - krapp 6y ago
    Yeah, unfortunately the entire javascript ecosystem is ridiculously over-engineered. In my day, all you needed was a text editor. Now you need a package manager and an abritrarily deep dependency tree of libraries, a complex toolchain and a test framework to write Hello World... often in another language that gets compiled into javascript. It was a simple, almost elegant language. You looked at a JQuery module, and you could understand it, modify it on your own, and use it without needing to understand the quirks of sixteen distinct build systems that would just be obsolete by next month. No one could delete a repository and break your software. There wasn't a single company and a single package manager basically controlling everything. There was competition and innovation and... I'll be in the angry dome if anyone needs me.
dragonwriter 6y ago
> It's kinda sad that JavaScript needs so many lines of code to figure out if a number is even, but understandable due to its dynamic nature. Except it doesn't need that many, and what it does need is due to the choice of main numeric type, not it's dynamic nature; almost all the line count in is-odd is about producing superfluously detailed error messages in the case of invalid values, and that includes the is-number dependency. The only check actually needed to deal with input for which the substantive check is incorrect is the isSafeInteger check (which subsumes all the others), which would be needed even if JS was a static-typed language, since this function operates by design on the Number (IEEE-754 double precision binary float) type, not the more recent BigInt type.
ksaj 6y ago
Honest question (has the potential to sound sarcastic): Is there a reason to test if the input is a number before testing if it is an integer? I would expect that it doesn't matter if isInteger receives a number, character, decimal, null, or whatever as long as the isInteger test can in fact detect if the input wasn't an integer, and subsequently let you know it was expecting one. The given code seems to suggest there might be non-numerical integers out there. I imagine something like this: isNumber("A") => 'expected a number' isNumber(2.2) => True isInteger(2.2) => 'expected an integer' isInteger(2) => FINALLY YOU GOT IT! In other words, a high level construct is being treated as if it were a low level construct, which would seemingly create a lot of duplication at run time. In Lisp, for example, I have only ever directly checked evenp or oddp without using numberp or integerp first, and haven't seen anything instructing that it should be done any other way. There would surely be a speed penalty if those tests were done separately before calling evenp, since evenp itself would obviously test those cases already. I can't think of any input value that isn't a (numerical) integer that would trip up evenp or oddp, given that only an integer could possibly pass either test.

by wsc981 6y ago

krapp 6y ago

>It's kinda sad that JavaScript needs so many lines of code to figure out if a number is even, but understandable due to its dynamic nature It doesn't. Javascript doesn't need this many lines of code to figure out if a number is even. A simple modulo 2 check works just fine.

wsc981 6y ago
Ah, so I guess it's just some over-engineered piece of code. Again I'm no web dev, so very limited JavaScript experience. Well, at least the author made it clear it was code from back when he was still learning JavaScript.
- krapp 6y ago
  Yeah, unfortunately the entire javascript ecosystem is ridiculously over-engineered. In my day, all you needed was a text editor. Now you need a package manager and an abritrarily deep dependency tree of libraries, a complex toolchain and a test framework to write Hello World... often in another language that gets compiled into javascript. It was a simple, almost elegant language. You looked at a JQuery module, and you could understand it, modify it on your own, and use it without needing to understand the quirks of sixteen distinct build systems that would just be obsolete by next month. No one could delete a repository and break your software. There wasn't a single company and a single package manager basically controlling everything. There was competition and innovation and... I'll be in the angry dome if anyone needs me.

dragonwriter 6y ago

> It's kinda sad that JavaScript needs so many lines of code to figure out if a number is even, but understandable due to its dynamic nature. Except it doesn't need that many, and what it does need is due to the choice of main numeric type, not it's dynamic nature; almost all the line count in is-odd is about producing superfluously detailed error messages in the case of invalid values, and that includes the is-number dependency. The only check actually needed to deal with input for which the substantive check is incorrect is the isSafeInteger check (which subsumes all the others), which would be needed even if JS was a static-typed language, since this function operates by design on the Number (IEEE-754 double precision binary float) type, not the more recent BigInt type.

ksaj 6y ago

Honest question (has the potential to sound sarcastic): Is there a reason to test if the input is a number before testing if it is an integer? I would expect that it doesn't matter if isInteger receives a number, character, decimal, null, or whatever as long as the isInteger test can in fact detect if the input wasn't an integer, and subsequently let you know it was expecting one. The given code seems to suggest there might be non-numerical integers out there. I imagine something like this: isNumber("A") => 'expected a number' isNumber(2.2) => True isInteger(2.2) => 'expected an integer' isInteger(2) => FINALLY YOU GOT IT! In other words, a high level construct is being treated as if it were a low level construct, which would seemingly create a lot of duplication at run time. In Lisp, for example, I have only ever directly checked evenp or oddp without using numberp or integerp first, and haven't seen anything instructing that it should be done any other way. There would surely be a speed penalty if those tests were done separately before calling evenp, since evenp itself would obviously test those cases already. I can't think of any input value that isn't a (numerical) integer that would trip up evenp or oddp, given that only an integer could possibly pass either test.