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

Left-pad as a service

left-pad.io

Post reply on HN
Print view View original

71–80 of 269 posts

Re: Left-pad as a service

#71

Post by Manishearth »

naasking wrote: post #59
pdkl95 wrote: post #47

Earlier quoted context omitted.

> How stupid of people to reuse small often used functions that only do one thing well. This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. > trust their package manager That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes h…

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.

> The cost of a dependency for a good package manager is zero

The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.

Re: Left-pad as a service

#72

Post by deong »

naasking wrote: post #59
pdkl95 wrote: post #47

Earlier quoted context omitted.

> How stupid of people to reuse small often used functions that only do one thing well. This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. > trust their package manager That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes h…

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.

"Zero" isn't a cost of anything -- there's no free lunch.

NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to

    function whatever() {
        return "WHHEEEEEEE!!!";
    }
and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's responsibility to vet changes. Obviously curated package managers like those used by most Linux distributions do carry some responsibility, but even then, there's not ZERO risk.

Re: Left-pad as a service

#73

Post by return0 »

andy_ppp wrote: post #8

Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. How stupid of people to reuse small often used functions that only do one thing well. How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM…

I think you're taking it too seriously. This criticism is a good think for npm. Too much cheerleading inevitably leads to lower quality in most communities. I assume people are not going to quit using npm anyway (although I don't use it myself).

Re: Left-pad as a service

#75

Post by naasking »

Manishearth wrote: post #71
naasking wrote: post #59

Earlier quoted context omitted.

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.

> The cost of a dependency for a good package manager is zero The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.

I said a good package manager. The fact that the npm package database is fully mutable is a huge problem.

Re: Left-pad as a service

#76

Post by beeboop »

Tomorrow: left-pad.io announces $120 million investment at $1.2 billion valuation

Month from now: left-pad announces purchase of $170 million office building in SV to house their 1200 employees

Re: Left-pad as a service

#77

Post by tromp »

TickleSteve wrote: post #13
maremmano wrote: post #6

What about splitting left and pad in two microservices?

3 maybe.... iteration-as-a-service also??

2 micro-services should suffice for all computation:

    $ curl 'https://api.S.io/?x=x&y=y&z=z'
    {"S":"x z (y z)"}

    $ curl 'https://api.K.io/?x=x&y=y'
    {"K":"x"}

Re: Left-pad as a service

#78

Post by naasking »

apalmer wrote: post #67
naasking wrote: post #59

Earlier quoted context omitted.

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.

no this is the fundamental engineering issue... there is no magically mythical perfect package manager, and even if one exists there is a real intrinsic cost to adding a dependency. It is not a huge cost... it is minor... but the benefit of using a one line package is also minor... so when you are making a minor trade off over and over again as with npm where its not unsually to end up depending on 1000s of packages.…

I never said perfect, I said good. Some basic properties are that upstream changes don't break downstream dependents if you've protected against automatic version updates.

Re: Left-pad as a service

#79

Post by deong »

andy_ppp wrote: post #20
eknkc wrote: post #16

Earlier quoted context omitted.

I use a lot of micro modules. And I think micro modules are a good idea. But this whole thing is freaking funny. You gotta acknowledge that.

I dunno; I think it's a balancing act between dependencies and code reuse. I think npm needs to not let people unpublish stuff without thought - that is where the problem is and I'm sure they are thinking about a solution to this. I think a lot of this is implying "don't use micro packages on your package manager, copy and paste code in helpers.js FTW". I've seen people advocating this as if it's a better solution th…

What's that, you say? I can't "unpublish" my own code? Fine then, here you go.

    $ echo "function leftpad(str, len, ch) { return ""; }" > leftpad.js
    $ git commit -a -m "fuck you" && git push
There is (obviously, I would say) no possible solution to the problem of the maintainer of a module you depend on deciding to mess with you. The only serious way to even make a go of it is to move your repository to a curated model where you (in this case, the NPM owners themselves) personally vet all contributions before allowing them in, and even then, I'm confident I can slip something into my own code that will cause problems if I want to -- it's code that I wrote and I've maintained for years and that you've looked at briefly every once in a while.

Re: Left-pad as a service

#80

Post by opmac »

morsch wrote: post #52
creshal wrote: post #35

Earlier quoted context omitted.

Even the Java ecosystem managed to get their crap together and make the excellent Apache Commons library collection to deal with a similar situation (anaemic to useless standard library). C++ has STL and Boost. Only the PHP and JS communities seem to think that not having a solidly designed "base" library is fine (and even PHP seems to be getting better at it with 7).

The Java standard library is anemic? As in Java SE? That's rich. Java SE is an everything but the kitchen sink standard library, with functionality like collection classes, local and networking IO, windowing toolkits (more than one), database connectivity, the list goes on. There is no language with a less anemic standard library, and Java SE is often criticized for being too large.

This is true. One wonders if OP has actually seen the vastness of Java SE or is just "hating" to "hate".
Post reply on HN