Live data from Hacker News

Left-pad as a service

left-pad.io

131–140 of 269 posts

Re: Left-pad as a service

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

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

I don't get the supposed irony.

Beyond a certain level it is indeed stupid of them.

And the examples we've seen were all below that level.

Re: Left-pad as a service

#132
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

Only if one doesn't understand the notions of opportunity cost, code debt, and several other things besides...

Re: Left-pad as a service

#133

Earlier quoted context omitted.

> C's stdlib, `math.h`, `string.h` are good but don't have string padding functions Of course they do; how would you align printouts otherwise? $ cat main.c #include int main() { (void) printf ("%42s\n", "hello"); // right-align, 42 chars (void) printf ("%-42s\n", "hello"); // left-align } $ gcc main.c $ ./a.out | cat -A hello$ hello $ $ ./a.out | wc -L 42

Of course you can use `asprintf` to pad a string like you can use a for loop to pad a string in JS. But it's not a dedicated named function to pad strings like the `leftpad` we're discussing. Kind of missing the point of the argument. Given how simple and popular `left-pad` module is (indicating the principle the community uses to determine granularity), I'd guess that if `String.format` was available in JavaScript t…

It's a memset followed by a strncpy, hardly worth linking to a library for. You'd be done writing the function before you finish googling for an existing one.

Re: Left-pad as a service

#134
post #72

Earlier quoted context omitted.

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

Except a good package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates. Seriously, the properties of good package management should be obvious by now. Any design that can break dependents and there's nothing they can do to protect themselves is broken.

And wait till you hear what a sufficiently smart compiler can do!

http://c2.com/cgi/wiki?SufficientlySmartCompiler

Re: Left-pad as a service

#137
post #112
post #62

Earlier quoted context omitted.

Javascript has an excellent standard library - lodash. Here is its string padding: https://lodash.com/docs#pad . Lodash also ships hundreds of independent npm modules for those who don't need the entire package. Here is pad as an independent package: https://www.npmjs.com/package/lodash.pad . Lodash is here today, it works, it is reliable, and it doesn't pull the rug from under you.

That's not a standard library.

Sure, but one reasonably cohesive library is better than a whole mess of tiny ones.

Re: Left-pad as a service

#138

Earlier quoted context omitted.

> C's stdlib, `math.h`, `string.h` are good but don't have string padding functions Of course they do; how would you align printouts otherwise? $ cat main.c #include int main() { (void) printf ("%42s\n", "hello"); // right-align, 42 chars (void) printf ("%-42s\n", "hello"); // left-align } $ gcc main.c $ ./a.out | cat -A hello$ hello $ $ ./a.out | wc -L 42

Of course you can use `asprintf` to pad a string like you can use a for loop to pad a string in JS. But it's not a dedicated named function to pad strings like the `leftpad` we're discussing. Kind of missing the point of the argument. Given how simple and popular `left-pad` module is (indicating the principle the community uses to determine granularity), I'd guess that if `String.format` was available in JavaScript t…

A function is dedicated if it is well-suited for a use case. It does not require it to be ill-suited for other use cases.

Either you arguing that `left-pad` is not a "dedicated" function for padding by 42 characters, because it can also pad for 43 or 41, or I don't understand you at all?

Post reply on HN