Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

haneycodes.net

Post reply on HN
Print view View original

401–410 of 887 posts

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

#401

Post by phaedryx »

tjmehta wrote: post #339
runin2k1 wrote: 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…

With how weird javascript can be about numbers, it actually didn't surprise me that your module existed.

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

#403

Post by nikolay »

jestar_jokin wrote: post #260
nikolay wrote: post #152

Earlier quoted context omitted.

Allocate and join an array of blanks just to repeat a string is acceptable?!

Joining an array of strings is sometimes better than concatenating a string in place, yes. Consider the following: 1: var str = 'foo'; 2: str += 'bar'; 3: str += 'baz'; At program load, you have three string constants, 'foo', 'bar', and 'baz'. At 1, 'str' becomes a pointer to the string constant 'foo'. At 2, 'str' becomes a pointer to a string 'foobar'. Memory is allocated to store this string. At 3, 'str' becomes a…

You'll be surprised, but my implementation is, roughly speaking, 10 (Chrome) to 100 (Safari) to 200 (Firefox) times faster [0], depending on the browser!

[0]: https://jsfiddle.net/nikolay/Lgshxrk8/

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

#404

Post by nikolay »

Macha wrote: post #182
nikolay wrote: post #152

Earlier quoted context omitted.

Allocate and join an array of blanks just to repeat a string is acceptable?!

I guess I'm also as guilty of looking at input/output rather than implementation here.

Here's a benchmark [0]!

[0]: https://jsfiddle.net/nikolay/Lgshxrk8/

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

#405

Post by [deleted] »

n0us wrote: post #368
coldtea wrote: post #354

Earlier quoted context omitted.

> TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?

No, you see "is-bigger-than-5" clearly does 4 different things. You need these modules: module.exports = exec("==="); module.exports = bigger(a, b){return a > b}; module.exports = () => return "than"; module.exports = (a) => a.search('ABCD...'); .. or something like that. These are all plugins of course.

[deleted]

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

#406

Post by mbrock »

dandelany wrote: post #191
dozzie wrote: post #79

Earlier quoted context omitted.

> I don't see anything wrong with using a pre-made left pad function. Why waste time and lines of code implementing something so trivial when there is already a solution available? I'll tell you why. The least important ones is that downloading such trivial module wastes bandwidth and resources in general (now multiply this by several hundred times, because of dependency fractal JS sloshes in). I would also spend muc…

Finding this module on NPM or npmsearch.com is pretty trivial compared to ensuring you implement this in a way that catches every edge case. > It manifests in much slower bug fixing I don't buy this at all, because I've done it myself many times. If you're waiting on a PR from the original repo owner to fix a Production bug, you're doing it wrong. It's trivial to copy the dependency out of node_modules and into your…

What are these arcane edge cases everyone is so afraid of?

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

#407

Post by bluejekyll »

userbinator wrote: post #350
lewisl9029 wrote: post #206

Earlier quoted context omitted.

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…

Small modules are easy to reason about 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. By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand, and understanding the big picture is vital to things like debugging and making systems which are effici…

Perhaps another reason for this is that Javascript is inherently unsafe. 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.

Other languages handle this with compilers, may be strongly typed, and/or have features that don't allow nulls. Javascript doesn't exactly have that luxury. So maybe it makes sense in Javascript, where it wouldn't in other languages (though one could argue this is a flaw in the language design).

edit: to be clear I'm not really defending the practice, but trying to give a little perspective.

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

#408

Post by lewisl9029 »

simula67 wrote: post #400
lewisl9029 wrote: post #373

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…

> 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 such failure modes.

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.

> The point is, breaking everything into micro-modules can have benefits and costs. Ultimately, it is an engineering trade-off.

Agreed. And I don't think nearly as many people are erring on the extreme side of this tradeoff to the degree that he's describing.

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

#409

Post by lsc »

lewisl9029 wrote: post #206
runin2k1 wrote: 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…

My problem is one of productivity. There's already a standard library, and if it's a language I've been using for a while, I probably remember most of it. I can pretty much go straight from my thought of what I want done to typing it out, much like typing English. If you force a 'cache miss' and force me out of my head and into a documentation search, well, that's going to have a significant effect on my performance. If the function is well-named, it has less of a cost in reading the code, but there's still a cost, because what if it's slightly different? I have a pretty good feel for the gotchas in much of the standard library of the languages I use. I have to stop and check what the gotchas of your function are.

Yes, at some point the complexity cost of gluing together the standard library functions to do something becomes greater than the lookup cost of finding a function that does what I want; but I am saying that adding more functions is not costless.

Post reply on HN