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

101–110 of 269 posts

Re: Left-pad as a service

#101

Post by roddux »

andy_ppp wrote: post #37
roddux wrote: post #30

Earlier quoted context omitted.

>How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip? By signing packages and not allowing literally anybody to re-upload a brand new package that does something completely different under the name of an existing, widely-used package. There's not much excuse for that in any respectable package manager.

Okay so have you checked all of the apt repos you've added to sources over the years or has one of the ppa's changed to something malicious?

I use Arch and only official sources, that are checked over and signed by a small well-trusted team[1]. Nothing like npm's model.

[1]: https://www.archlinux.org/master-keys/

Re: Left-pad as a service

#102

Post by ksml »

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

I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell

Re: Left-pad as a service

#103

Post by afandian »

rdancer wrote: post #100
afandian wrote: post #17

Earlier quoted context omitted.

I think it's less smugness (there certainly is some) and more disbelief / unfamiliarity. JS isn't the first language without great libraries (C's stdlib, `math.h`, `string.h` are good but don't have string padding functions, for example) so there's precedence going back a very long way. Most solutions involve coming up with a utilities library that contains the basic things (like a math library, or a strings library)…

> 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 there would still be a library to provide `leftpad`.

Re: Left-pad as a service

#105

Post by icebraining »

deong wrote: post #79
andy_ppp wrote: post #20

Earlier quoted context omitted.

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…

That wouldn't mess with me. It would just create a new version, while my dependencies tracking file is locked to the previous one. I only fetch new versions to my local development machine, and only update the dependencies file after testing it locally and on the staging server.

Re: Left-pad as a service

#106

Post by KirinDave »

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…

> How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting.

Well... Maybe a better word is naive? Because every additional package dependency is a risk. It's a risk in a security sense (has anyone ever wondered what is in left-pad in your organization?) and an engineering sense, as demonstrated by the latest JavaScript Bro if the month's industry-crushing personal power fantasy that you all cheerfully turned into reality by letting him control trivial but critical parts of your codebase.

It's true that to an extent, that risk is unavoidable if you want code reuse. Too little code sharing has the exact same problem! But I think that arguing that any programmer in a position to need left-pad should be given edit rights to a non-toy project is what were needling you all about.

The node communtiy has gone too far in one direction and embraced reuse for reuse's sake, not to address any real complexity.

Re: Left-pad as a service

#107

Post by TickleSteve »

tromp wrote: post #77
TickleSteve wrote: post #13

Earlier quoted context omitted.

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

...now theres an idea for a new language.... slightly verbose tho....

Re: Left-pad as a service

#108

Post by sod »

jasongill wrote: post #65
jasim wrote: 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.

Lodash only got padLeft in version 3.0.0 (released last January), and then that method was renamed to padStart in 4.0.0 this January, so it's not exactly the paragon of reliability (although I understand your sentiment)

dalton likes to name methods as ecmascript itself, what I very much appreciate. padStart() was proposed as standard after lodash 3.0.0 was released. So he changed it on the next major release:

https://github.com/tc39/proposal-string-pad-start-end

Re: Left-pad as a service

#109

Post by capitalsigma »

jameshart wrote: post #36
c4n4rd wrote: post #14

This is really exciting!!! I was a bit disappointed that the right-pad will be out only in 2017. I am looking forward to that release because there is a high demand for it now. What kind of load balancing is being used on the back-end? I called leftpad(str, ch, len) with the length I needed and noticed that is not very scalable because it is blocking. A better approach I would recommend to those using it is to call t…

Best practice for performance for large left-pad jobs is to call the service recursively using mapreduce. Remember that left-pad(str,pad,n) is equal to left-pad(left-pad(str,pad,n/2),left-pad("",pad,n/2),n). This should run in logarithmic time and is highly parallelizable. If you don't like the "" magic string in there you could replace it with a call to left-pad(null, null,0).

oh god it's too real

Re: Left-pad as a service

#110

Post by mdemare »

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.

Java SE includes a lot, but it does emphatically not include a reasonable amount of useful string methods. These are the javadocs for string: https://docs.oracle.com/javase/7/docs/api/java/lang/String.h... and these are the rubydocs: http://ruby-doc.org/core-2.3.0/String.html

The difference is absolutely massive. When working on Java projects, I've always included commons/StringUtils reflexively, and even then Ruby is quite a bit ahead.

The same applies to collections / enumerables. There's a lot in Ruby that I don't like, but powerful "batteries included" standard libraries for the basics like strings and collections are the bedrock of any programming language. It only takes hard work to write them and test them, not any specific skill, so there is no excuse for all the language out there that are skill lacking, in 2016, a sensible collection of utility methods.

Post reply on HN