Live data from Hacker News

NPM and Left-Pad: Have We Forgotten How to Program?

haneycodes.net

701–710 of 887 posts

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#701
post #7

Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…

Author of "is-positive-integer" here. I will admit the implementation is pretty funny, but I move-out all single-purpose utils out of projects to modules for a bunch of reasons. DRY is the most obvious one, but one that may be less obvious is for better testing. I move out modules so I can write really nice tests for the independent of the projects I am using them in. Also, I tend to write projects w/ 100% test cover…

It would be really, really great if this function was not in its own module, but was part of a larger library in which all such functions of related modules were captured, without the (cognitive and other) overhead of the separate packaging.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#702

Surely there is a need to standardise on a set of well-maintained "batteries included" packages.

That is what PHP has, and it received countless attacks on that approach during the years; although most of those attacks were due to the inconsistent function naming.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#703

Earlier quoted context omitted.

> Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand. Regardless, the book metaphor misses a lot of the nuance. Of course taking the approach to an extreme would be detrimental.…

> A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand No, that would not be an apt metaphor for the problem he is describing. > Regardless, the book metaphor misses a lot of the nuance. Not if you are trying to understand the point he is trying to make. Is there any cost to creating modules, uploading them to npm and using the…

> for the problem he is describing.

Because it is a strawman.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#704
post #633

Earlier quoted context omitted.

Bloat in the source code, build system, dependency management, overheads per submodule, complexity. I'm not arguing that there shouldn't be a math module but that you shouldn't split it up into such (imho) crazy small parts. Closure Compiler can remove any unused functions.

It's not bloat in the source code - if you don't care which pieces you depend on you declare a dependency on math, if you do care you list the specific pieces. It shouldn't be (impactful) bloat or overhead in the build system or dependency management. That stuff should just handle it. Most of the time you don't care and can just declare the dependency on math and let the closure compiler handle it. But sometimes it m…

Ooops. Upvoted you by mistake. Why would it be so important?

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#705

Earlier quoted context omitted.

> A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand No, that would not be an apt metaphor for the problem he is describing. > Regardless, the book metaphor misses a lot of the nuance. Not if you are trying to understand the point he is trying to make. Is there any cost to creating modules, uploading them to npm and using the…

> No, that would not be an apt metaphor for the problem he is describing. That's because I don't agree that the problem he is describing exists, or at least not to the degree he's describing, which was full of hyperbole. > Is there any cost to creating modules, uploading them to npm and using them in other projects ? Clearly there is, as is shown by the world-wide breakage from yesterday. This is probably only one of…

> This was a failure on npm's side by including a functionality that allows users to trivially remove packages from a package management system that is used by hundreds of other packages, something that most major package management systems have decided was a bad idea.

That is emphatically not the problem. The author of those modules could have just as easily modified the code instead of deleting it:

    function leftpad(str, len, ch) {
        // NPM won't let me delete modules, so here you go
        return "";
    }
Now you'd have an even harder time figuring out what happened to your code that you did if the module just disappeared. What you're asking for is basically for the repository to adopt a policy of "all maintainers must be given free rein to get their modules correct and keep them maintained, but they shouldn't have the ability to do anything that causes problems downstream" which is impossible and frankly silly.

The problem is the dependency, not the precise mechanism by which that dependency screws you when it goes bad.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#706
post #685
post #587

Its interesting how everyone used this as a chance to attack the small modules approach. This approach definitely has downsides, but the problem caused by leftPad being unpublished wasn't one of them. If jdalton declared a jihad on arrays tomorrow and decided to pull all array related functions from lodash, we would have the exact same problem. If kriskowal decided that Q must mirror built in Promise and published a…

Would people automatically update to the new versions of the libraries you mentioned? The problem with unpublishing is that it changes an existing version. If instead of depublishing a correctly versioned empty module named leftpad was pushed to npm (increment major, because a non-implementation is incompatible with an implementation), there would not be half as much pain. As long as unpublishing exists, micromodules…

Which means unpublishing is the problem, not micromodules (in this particular case).

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#707

Earlier quoted context omitted.

JS does not have an Integer type, so (x > 0) does not work. Now if you add all those checks necessary to see whether you're actually dealing with an integer here, you get to a point where you cannot be sure anymore whether there aren't any weird type coercion issues there and need to start writing tests. Suddenly your whole positive integer check took 1h to write and you still cannot be sure whether there's something…

A module doesn’t solve that kind of type confusion, though. Static typing does. The next best thing in JavaScript is passing consistent types of values to your functions, so just write function isPositiveInteger(x) { return x > 0 && Number.isInteger(x); } and always pass it a number. (Of course, this shouldn’t even be a function, because JavaScript is confused about the definition of “integer” – maybe you really want…

I would swap the expressions on each side of the '&&' around. While JS doesn't care (as it'll apply '>' to just about anything, even in strict mode), this is perhaps a stronger statement of intent:

    return Number.isInteger(x) && x > 0;
Thus the more general assertion (is it an integer) guards the more specific specific one (is it greater than zero).

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#708
post #221

Maybe some people just want to claim they have a published module. Making them feel some sort of achievement or glory.

Not just making them feel... I think this may be targeted towards recreuiters, who may be impressed by the sheer amount of npm modules someone has published.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#709
post #7

Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…

It's interesting to me that people find this convincing. I find it to be complete insanity. People need their libraries, but putting everything in tiny buckets is just not working. Why aren't people working on good utility libraries instead?

There's even some guy calling for a "micro-lodash". To me, as a Python engineer, lodash [1] is already a tiny utility library.

I guess it's also about the fact that JS is a pretty bad language. That you need a one-line `isArray` dependency to `toString.call(arr) == '[object Array]'` is crazy.

[1] https://lodash.com/docs

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#710
post #7

Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…

Author of "is-positive-integer" here. I will admit the implementation is pretty funny, but I move-out all single-purpose utils out of projects to modules for a bunch of reasons. DRY is the most obvious one, but one that may be less obvious is for better testing. I move out modules so I can write really nice tests for the independent of the projects I am using them in. Also, I tend to write projects w/ 100% test cover…

Actually, thats a good reason to use trivial functions like the one described. Hopefully the author has discovered all of the quirks in Javascript that might affect this. It will likely be a lot more tested than any version I would write.

As someone who spends 80% on the back end, I often get bit on the ass from JavaScripts quirks when I need to add some front end stuff.

Post reply on HN