Comment by saurik
11 years ago
> By relying on these small rigorously tested libraries they are avoiding the need to test their own code, and thus avoiding basic null check or conversion errors.
In practice, many, if not most, of these one-line modules don't even work correctly, and it is difficult to get people to care to collaborate on fixing them instead of just replacing them with a new one-line module that works slightly better as the concept of complex collaboration to perfect one line of code is so foreign to a generation of developers who would rather just throw code to the world and never look back (an issue made all the worse as tiny bugs in these one-liners can almost seem dangerous to fix when you aren't really sure how they are being used: maybe it actually is better to not fix anything and just have people rely on the replacement better module :/).
Odd, the ones I use all have tests, thousands of downloads, and active bug trackers. If I reinvented the wheel, or copy pasted, I wouldn't get those things.
Doing a for loop is not equal to re-inventing the wheel.
Words and phrases have lost their meaning nowadays.
By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules.
Maybe they didn't forget how to program, as the article implies; maybe they never knew how to program in the first place.
Writing your own solution, when you could use a common widely known solution, exactly matches both writing your own left pad and inventing your own wheel.
> By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules.
If there was, it would have been published and people would be depending on it. Instead, people use the stdlib first, then big lego bricks like underscore, then (when they don't want the bulk of big lego bricks) smaller lego bricks. A single capitaliseMap() might be in there but it's a much more specific case than padding.
10 replies →
The OP's example ( is-positive-integer) has tests, and is only three lines long, and is on major release version 3.X, because despite all that, it had serious problems in versions 1 and 2.
"Serious problems in versions 1 and 2" suggests that it might be a good idea not to write your own version 1.
But to be explicit about the history: version one[0] had dependencies. Version two[1] had no dependencies, and a comment on github suggests that it might be wrong but I can't immediately see how. Version three[2] is a different implementation, and adds another export.
[0] https://github.com/tjmehta/is-positive-integer/commit/3003f9...
[1] https://github.com/tjmehta/is-positive-integer/commit/b47e90... - it should return false for 0, so I'm not sure what the commenter is getting at
[2] https://github.com/tjmehta/is-positive-integer/commit/3cdfe1...
Case in point: the left-pad package has quadratic complexity.
Depends on the JS implementation in question. And I think node uses one that optimizes string concatenation, possibly making that the fastest way to do it.
Yeah, as far as I know in modern JS engines += is actually faster than using an array.
[citation needed]
It's really nice how we once again depend on "I think some guys do it like this" for performance. What happened to standards?
What's next? SEO for code?