Live data from Hacker News

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

haneycodes.net

711–720 of 887 posts

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

#711
post #642

Earlier quoted context omitted.

What I want to know is how many systems does the author of is-positive-integer have implicit root access to? Sounds to me like publishing oneliners on NPM is a trivial way to build a botnet.

Seems like the answer is "none" by default, from https://docs.npmjs.com/misc/scripts#user > If npm was invoked with root privileges, then it will change the uid to the user account or uid specified by the user config, which defaults to nobody. Set the unsafe-perm flag to run scripts with root privileges.

That's good, even if nobody is perfectly enough to a botnet. I thought more of the user running the node application.

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

#712
post #633

Earlier quoted context omitted.

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?

Maybe you're running on an embedded processor that can do sin/cos/tan with high performance but sinh performance is bad. Maybe part of your project needs to depend on an old version of sinh with a correctness bug so that you can reproduce existing calculations, so you don't want any other parts of the code depending on sinh. Maybe your legal team doesn't want you using sinh because they believe the implementation might infringe some patent.

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

#713

Here's a quick rule of thumb. If it's the kind of function you would ask a candidate to write at the start of a job interview, you shouldn't be importing a separate module to do it.

Should you rewrite it for every project you need it in, or copy and paste from the last one?

Should tests also be rewritten or copied each time you do this?

What do you do when you've used it in multiple projects and you find a bug or performance issue?

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

#714

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…

I get that author's point, but do you REALLY need a dependency module that tells you the type of something? That's not a Lego block; that's an excuse.

When using a language where

    isArray(arr)
turns into

    toString.call(arr) == '[object Array]'
...then I guess that's more reasonable than if you use something sane.

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

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

[deleted]

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

#716
Dependencies are one side of the problem. Unavailability of binaries and dogmatic use of dynamic linkage are the other side.

When I installed a simple lines-of-code counting tool through Macports the other day I accidentally opened the door to dependency hell as gigabytes of not even remotely related stuff started to build [1].

Without a doubt something is going very wrong with Free Software and package managers. On the other hand, never look a gift horse in the mouth so I may not even be the right guy to complain here.

[1] http://pastebin.com/cAZgbaFN

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

#717
post #177

Earlier quoted context omitted.

> Why would I implement left-pad myself when there is already a well-tested implementation that I can install? You call 4 basic assertions "well-tested"? https://github.com/azer/left-pad/blob/master/test.js

a) I think that's a fine number of tests for a module this simple, which is itself an argument in favor of small modules. And I think it's four more assertions than anyone implementing this inline in a project would have. b) The details of this particular project are orthogonal to the philosophy of small modules generally. Whether or not this module is well implemented or well tested has no real relation to whether o…

a) It's about half of what I'd write for my own, where I would make sure to test all edge cases (e.g. input string being longer than padding length) as well as Unicode characters. Writing expectations is cheap, fixing bugs later isn't.

b) I agree, but you were the one offering "well-testedness" as an argument :)

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

#718
post #578
post #442

Earlier quoted context omitted.

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

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.

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

#719
post #634
post #544

Earlier quoted context omitted.

Libraries/modules should help to solve complex problems where writing your own version is not optimal. Single line functions as modules, on the other hand, won't help you compete with Google or Microsoft and result in more problems than they solve. If a simple padding or "is this int positive?" is a complex problem, well, there are different professions than programmer's..

The less code you write, the less code you have to maintain. Even if it's just one less thing, it's a win. The comonJS module pattern also helps tremendously, as your requires are block/function scoped. It makes it trivial to refactor (remove/rewrite) code.

In a perfect world yes, but in the real world, with unreliable dependencies and their imperfect management, it doesn't come for free.

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

#720
post #462
post #420

Earlier quoted context omitted.

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.

The difference with C is that with a good linker, functions you don't call are removed from the resulting binary (or are maybe not even in the binary if you are dynamically linking to the c runtime). With javascript however, if you import a hypothetical "math.js" instead of just "sin.js", "cos.js" or "tan.js", then you'll need to download and evaluate a whole bunch of javascript that you might not need. I'm not defen…

Webpack 2 (probably the closest thing to a JS linker) can do that same tree shaking.
Post reply on HN