Live data from Hacker News

I will pay you cash to delete your NPM module

drewdevault.com

41–50 of 60 posts

Re: I will pay you cash to delete your NPM module

#41

Earlier quoted context omitted.

The article mentions this, and links to the same page.

Still, though, could there not be a similar scheme where instead of unpublishing the module, the maintainer intentionally inserts a divide by zero somewhere and pushes it as a minor update?

To my mind, that crosses some invisible line, that unpublishing a module does not.

Re: I will pay you cash to delete your NPM module

#43
post #14

Earlier quoted context omitted.

How is this "satire"? What is this satirizing?

You could call it a modest proposal.[1] [1] https://en.wiktionary.org/wiki/modest_proposal

You could, that’s interesting, had never heard of that. Thanks.

Re: I will pay you cash to delete your NPM module

#46
post #19

Why not build a scanner for common structures like "isArray" and automatically submit a PR to replace the usage with built-in tools or something like lodash. (I know program comparison is akin to the halting-problem, but for simple templates it should work).

https://github.com/moxystudio/node-cross-spawn/pull/102

Re: I will pay you cash to delete your NPM module

#47
post #25

Earlier quoted context omitted.

Because he openly, in black and white, says it is satire?

How does this fall under the definition of satire? “the use of humor, irony, exaggeration, or ridicule to expose and criticize people's stupidity or vices, particularly in the context of contemporary politics and other topical issues.” Where’s the humor? Where’s the irony? What is he “satirizing”? He’s trolling and calling it “satire.”

[deleted]

Re: I will pay you cash to delete your NPM module

#48

I mean, that isArray example is exactly the kind of code that 99% of developers wouldn't come up with on their own, since it's not intuitive at all to check whether or not the value is an array in that way. If anything I would just be in favor of a name for the package that made it clear that it's intended for legacy compatibility.

It’s also wrong because the representation wasn’t exactly always deterministic in 2013 across all js engines. The right way to check for an array is value.constructor === Array, which also doesn’t really make any sense because an array in JS really is just an object with a length key and respective keys names 0…n.

Re: I will pay you cash to delete your NPM module

#49

I mean, that isArray example is exactly the kind of code that 99% of developers wouldn't come up with on their own, since it's not intuitive at all to check whether or not the value is an array in that way. If anything I would just be in favor of a name for the package that made it clear that it's intended for legacy compatibility.

That points to the underlying problem: a crap standard library. If extremely common functionality has to be outsourced to (short but) completely non-obvious third party modules, the standard library has failed at its core task.

Re: I will pay you cash to delete your NPM module

#50
post #48

I mean, that isArray example is exactly the kind of code that 99% of developers wouldn't come up with on their own, since it's not intuitive at all to check whether or not the value is an array in that way. If anything I would just be in favor of a name for the package that made it clear that it's intended for legacy compatibility.

It’s also wrong because the representation wasn’t exactly always deterministic in 2013 across all js engines. The right way to check for an array is value.constructor === Array, which also doesn’t really make any sense because an array in JS really is just an object with a length key and respective keys names 0…n.

I've been using JS on and off in various incarnations, and this sort of blows my mind. First because I don't think I've ever seen that approach used anywhere, and second because it would probably take me upwards of an hour (possibly a day) to work out whether that would actually work.
Post reply on HN