Hacker News Reader

Comment by raspyberr | Hacker News Reader

Reading issue #27 on the github page really gives an insight into..something: https://github.com/juliangruber/isarray/issues/27

View on HN

The biggest insight in that thread is how big of a jerk "PublicByte" is. I sure hope I never have th misfortune of working with that person or anyone like him.

Yeah, github desperately needs moderation. Maintainers should be able to flag issues, and prevent people who more then x flags from filing issues.

It added some moderation tooling in the last year or so, I'm not sure about that specifically though.

Blocking works nicely and prevents further interactions.

Some seriously relevant psychoanalysis of this behavior in this article (also on HN front page) about toxic workplaces: https://articles.tilt365.com/identify-destructive-leadership...

Yeah that person really dialed things up to 11 there. But I think it's a tone that stems from a legitimacy thing with javascript having a super low barrier to entry.

Did you actually read the function in this library. While yes it's a single line I'm convinced that anyone who thinks this is an "obvious" implementation hasn't actually read the code.

Actually I did read the function, and I thought about the cycles that toString.call(arr) == '[object Array]' costs.

... which only gets called if the native implementation of `isArray` is not found.

ES5 is a low requirement. I'd rather use a lib that did a better job than one that returns true for the string '[object Array]' or have the app decide for itself what its own types are.

Is there some other implementation you think would work?

Please use harrassment free language. You've broken a few comment rules. Can you review the community guidelines and refrain from breaking the rules?

https://news.ycombinator.com/newsguidelines.html

I don't understand the mindset of "you did it wrong once, so you can't do it anymore, you must let me do it for you."

Why is the fact that some devs sometimes screw up one-liners of any material importance to the existence of this library?

Some devs write code with bugs, does that mean they shouldn't write code any more? Is it either you write pristine, bug-free code on the first try for everything, or else you should be relegated to the back room gluing things together built by the _real_ devs? This is such snooty behavior that I'm not surprised at all by a response like the angry dude in there. He's an asshole for sure, but he's not totally wrong in my view.

I’m with you. Some people occasionally forget semicolons, should we have a library for that too? “Wrap all your statements in this pre-processor function call (it’s just another line in your build pipeline) and we’ll take care of the semicolons for you.”

It’s completely stupid that this kind of module gets used in the JavaScript ecosystem, but as the author points out, it’s not his fault, it’s downstream modules’ fault for actually using something so trivial.

It’s deeply unfortunate that the lack of a standard library in JavaScript combined with the constraint of wanting to minimize shipped code size in a language that resisted dead code elimination for a long time led to... whatever this is, instead of a comprehensive stdlib.

People keep saying this is "so trivial", denigrating anyone who would use this, but I am convinced they haven't even looked at the "one line of code" they are denigrating.

I've been a JS/Node dev for years now (granted, post a time when Array.isArray was part of the standard), and if someone asked me to write isArray, I wouldn't have done it like this, and I'm assuming there is a reason it was done like this.

What I really see is a bunch of typical "I'm a cooler dev than you" posturing for people who haven't even actually looked at the code. That's a shame because there is a valid discussion to be had around how lots of teeny dependencies can make the npm ecosystem brittle, but bullshit posturing around how any dev should be able to write this one line is just false.

Sure, ok. I can buy that this is not actually completely trivial, and that it's worth bringing code to solve this problem in from some other source.

Still, it's a shame that the specifics of the way the JavaScript ecosystem has evolved mean that it's commonplace to bring in a <10 line dependency to mitigate an extremely core lack of functionality, rather than have a first-party—or be able to sensibly import a third-party—standard library. I can't think of any other language ecosystem where this is normal.

Again, did you even read the package? This is part of the JS standard, and has been for years. This is basically just a polyfill for people that need to support very (very) old browsers.

Can't upvote this enough ...

Did you read the code? It is standard functionality, but only in newer Node versions and browsers. The linked package is basically a polyfill.

It is now, but it wasn't standard functionality back when this library was first published.

first commit is from 2013 [0], first Node that had Array.isArray was 0.1.15 from 2009 [1], thus making is as Node module was pointless, but polyfill for browsers might have some sense.

- [0] https://github.com/juliangruber/isarray/commit/c8601522e3136...

- [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.15/Cha...

Reply on news.ycombinator.com