Hacker News Reader

Comment by vsnf | Hacker News Reader

Dart has a lot of built-in methods similar to this. Yes, that includes `$n.isEven` and `$n.isOdd`. It's especially nice with iterables that have `.isEmpty` and `.isNotEmpty`. I make regular use of all four. It cuts down on clutter and makes the intent unmistakably clear. I think these JS packages, and Dart's inclusion of them in the stdlib are indicative of a clear need among programmers for unambiguous intention. Also, I suspect a lot of people, especially JS programmers, of whom a large percent is certainly made up of non-formally educated people, likely don't know that testing for even-ness can be done with modulo.

All of this is to say, instead of this being an indictment of the JS ecosystem and its programmers, its more indicative of a stdlib function that should exist but doesn't.

View on HN

I'd say there's a reasonable middle ground here where you can define isOdd where you need it:

    isOdd = x => x % 2 === 1
    ...

It's one of those things that doesn't pop up all that often and never changes. I've looked through my whole codebase and there are 3 occurrences.

Aside: I don't use Dart, but does that mean that you have to rely on each different type of iterable to implement these functions?

I don't quite know what you mean by "rely on" here, but the isEmpty fields are implemented on the iterator interface, so any of the standard container types implement it by default, including lists, sets, and maps.

Also to address other posts in the thread, while I don't think this specific example is worth indicting JS developers over, I do think the culture of infinite dependencies common to JS developers is. This shouldn't be an entire additional dependency. Just implement the modulo operation, or as parent suggests, make a nicely named utility function that wraps the modulo operation. But when the culture strongly encourages downloading micro packages for every little thing, I can hardly blame them for adding this into the pile of yet more things they've downloaded.

Ahhh, I see my confusion here. Got mixed up with the abstractions (isEven != isEmtpy) and thought there was something crazy going on with lists of numbers implementing isEmpty.

On the whole I do agree with you about all this mess. The JS stdlib has a lot to answer for.

Not defending isOdd in any way, but the example shows that even something as clear-cut as testing a number for oddness isn't that easy to get right:

isOdd(-1) === false

(-1 % 2 === -1)

Ha! Good catch. You’d think that with a math degree including algebraic number systems I would have spotted that.

>All of this is to say, instead of this being an indictment of the JS ecosystem and its programmers, its more indicative of a stdlib function that should exist but doesn't.

Surely by now they would have recognised a need for some standard math packages and then created one and all the new projects should be using that and people would have migrated? Especially given how fast FE seems to move.

Instead they are content with pulling a thousand dependencies and an intractable dependency system.

Is N%2==0 ambiguous for you?

To me? No. But its extra characters that I need to scan and process, it's syntax that can't be autocompleted by my LSP/IDE, and it's at least one mental leap away from what I really want to do. I am interested in the even-ness, not the remainder.

The simpler programming can be made to be, the better. I'm not going to die on the anti-modulo hill, I don't care that much about it. But I think it's silly to pretend that it's not overly complicated (even if only a little) for the task most commonly at hand.

Reply on news.ycombinator.com