Live data from Hacker News

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

haneycodes.net

561–570 of 887 posts

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

#561

What's with these kids and their "calculators". Back in my day we used a slide rule and we liked it! But seriously this is stupid. Programming shouldn't be the goal. Just because you can write a function doesn't mean you should. Every line of code you write is overhead that must be tested and maintained. I guarantee that if the author chose to hand roll code instead of using packages he'd have a lot more bugs. But he…

"Every line of code you write is overhead that must be tested and maintained."

The problem is, that modules doesn't solve problems magically. Every dependency should be tested, maintained and kept online as well, by somebody else, whom you have no control of. In turn, you have a bunch of black boxes that can blow up your application anytime. Of course, another extreme of write everything yourself is also bad, so it's a trade-off that must be considered carefully. I've build many systems during my career and one of the biggest nightmare I encounter is managing dependencies.

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

#562

Earlier quoted context omitted.

> This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/ama/issues/10#issuecomment-1... . If anything looking at sindresorhus's activity feed: ( https://github.com/sindresorhus ) perfectly supports the author's point. Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line f…

I think the gist of this whole discussion ( at least the OMG WHY?!?! ) part, can be easily explained by an excerpt from your example comment that sums up in a nutshell the all too pervasive mindset I've seen over the years: "...LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care a…

Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)

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

#563
post #509

Earlier quoted context omitted.

Wow, you were not kidding. I chose a random package of his [1], and indeed: a grand total of 1 LOC... This is madness. [1] https://github.com/sindresorhus/float-equal/blob/master/inde...

and it uses another 1LOC package. https://github.com/sindresorhus/number-epsilon/blob/master/i... and no, the edge cases argument does not apply to either of them. Wow.

Would you like to memorise that number yourself to use in your app?

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

#564
post #485

Earlier quoted context omitted.

Discoverability happens with standardization. Why search through millions of unknown packages when a standard library would have it all right there?

Yeah, I think the natural question here is: why doesn't TC39 round up all these basic packages and add them to the standard library? I've seen other languages criticized for having too large a standard library, but if this is the alternative... left-pad was released under WTFPL, so in this particular case there'd be no legal barriers to it. (And I'd assume that, for any libraries with a restrictive enough license, it…

Its not about legal barriers, its about the incredible amount of work to precisely specify everything, which is required for any web standard.

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

#565
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…

> 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 src, and then fix the bug yourself. Then when the owner accepts your PR, swap it back in. I don't understand the problem here.

You're working the problem around instead of having it solved. You're moving a library in your repository back and forth, while the library should never land there in the first place (or stay there until it stops being used).

But even if you don't agree with this strategy, it's still much more work than to just commit the fix and be done with it. And you still don't control who introduces bugs to your code with modules upgrades, having much bigger surface to random external programmers than you would if you only used things large enough to pay for themselves.

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

#566

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?

Do you seriously think that "word starts with a capital letter" is an easy function to write? I feel like you haven't spent enough time with Unicode.

return string[0] === string[0].toUpperCase();

You're welcome!

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

#567
post #171

Earlier quoted context omitted.

...and now you can have all the bugs introduced in all the versions of the library! Yay!

Or you could have all the bugs introduced in everyone's hand-rolled implementations of it. I'll take multiple versions of the library instead. It's much easier to track issues and submit patches to update their dependencies later.

> Or you could have all the bugs introduced in everyone's hand-rolled implementations of it.

Only one buggy implementation per project. Compare this to including the same library in dozen different versions, because dependencies have their own dependencies. And you can neither track the versions nor update them.

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

#568
post #515

Earlier quoted context omitted.

what you describe is the "-flto" option in GCC and I believe the equivalent in JS is donr by Google Closure compiler.

He described not Link Time Optimization (-flto), but the very basic linker functionality: to only include required functions. C/C++ has a weird compilation model where each source file is translated to machine code separately, with placeholders for unknown function addresses. Thus it is trivial to take only required functions. -flto, on the other hand, allows to reverse this process to allow interprocedural optimizat…

He's describing unused-function removal... which "-flto" is the correct option to use (on GCC). like you say, without this, removal is only performed within the compilation-unit, but my statement was quite correct.

@majewsky: what you're describing is more akin to "-ffunction-sections" and "-gc-sections" which will split ewach function into a separate section and garbage-collect those sections.

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

#569

Going down the "lots of tiny modules" route is about these three things: a) No standard lib in JS b) JS is delivered over the internet to web pages in a time sensitive manner ... so we don't want to bundle huge "do everything" libs. Sometimes its convenient to just grab a tiny module that does one thing well. There isn't the same restriction on any other platform c) Npm makes it really easy to publish/consume modules…

I think b) is true only because JavaScript tooling cannot perform dead code elimination. Other languages have big grab-bag utility libraries like lodash that don't hinder performance because a linker or runtime can avoid loading unused portions.

Yes it can https://github.com/rollup/rollup. Webpack 2.x can also do this.

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

#570
post #420

Earlier quoted context omitted.

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 J…

The equivalent in C would then be replacing #include and "-lm" with #include #include #include #include … and "-lsin -lcos -ltan -lsinh …" Which is nuts no matter what language you are coding in.

So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?
Post reply on HN