Live data from Hacker News

Left-Pad (2024)

azerkoculu.com

41–50 of 224 posts

Re: Left-Pad (2024)

#41
post #32

left-pad even being a package is pretty funny, no? How many bytes got pumped across CDNs, proxies, build pipelines, etc. just to write a tiny utility function? I'm all for taking advantage of existing solutions, but I can't wrap my head around needing to pad a string and thinking "oh, I bet there's a package for that"

Isn't it similar with AI now? How many prompts can already be solved with a simple web query? C&P but with extra steps

I'm pretty pessimistic about AI in general, but the quality of web query results has gone done so much I've resorted to asking an AI to get the short answer or the starting point that Google would have given me just a few years ago...

Re: Left-Pad (2024)

#42
post #25

Earlier quoted context omitted.

I don't see where the quadratic time complexity comes from. There's a single loop performing n operations in total, ie. O(n).

In each loop prepending a single character could take O(m) (moving all m characters one to the right) so combined O(nm) where n is the number of padding characters and m is the total number of characters in the string.

Only when the underlying JS implementation does this naively. In reality JS implementations do a lot of optimizations which often can reduce the time complexity.

Re: Left-Pad (2024)

#43
post #25

Earlier quoted context omitted.

The package's original implementation[1] also seems like it would have resulted in O(n^2) operation rather than desired O(n). [1] https://en.wikipedia.org/wiki/Npm_left-pad_incident

I don't see where the quadratic time complexity comes from. There's a single loop performing n operations in total, ie. O(n).

[deleted]

Re: Left-Pad (2024)

#44
post #25

Earlier quoted context omitted.

The package's original implementation[1] also seems like it would have resulted in O(n^2) operation rather than desired O(n). [1] https://en.wikipedia.org/wiki/Npm_left-pad_incident

I don't see where the quadratic time complexity comes from. There's a single loop performing n operations in total, ie. O(n).

Extending strings is not a linear-time operation. Behind the scenes, the JS runtime allocates new memory for it. In the naive case, you start by allocating 1 byte, then when you append to it, you need 2 bytes. So you allocate a new string of 2 bytes, and copy the data in. Each new byte is a new allocation, and a new copy of the entire string. That's how it's quadratic.

In practice, memory allocators tend to double the size of an allocation like this, which is still quadratic.

In practice, JS runtimes also tend to use data structures like Ropes for strings to handle this sort of issue. That brings it down to linear time in practice (I think?)

Re: Left-Pad (2024)

#45

Azer Koçulu has never been a scourge to the NPM ecosystem. Nobody forced anyone to use left-pad. The reason it got included in so many projects is due to messy transitive dependencies. Jon Schlinkert on the other hand is going out of his way to produce these micro libraries and then include them in his widely used legitimate projects (handlebars-helpers) with zero willingness to simply integrate them into the project…

On top of that, he only ran the script that NPM themselves provided him. Yes, the micro-package situation was absurd, but Azer Koçulu did nothing wrong. NPM did by forcibly taking his package, and then by providing him with scripts that were clearly unsafe to run. That Azer Koçulu got any blame for this is ridiculous.

Jon Schlinkert is a typical marketing A-hole. He should be banned from NPM and Github IMHO.

Re: Left-Pad (2024)

#46
post #19

> I have to admit that I don't understand half of this blog post It's because you haven't read al-Ghazali yet. (definitely the most pompous and self-important part of this post)

> Not driven by logic, anger...

I don't know that I fully buy this either, at least not the anger part.

I can look back on all this with wry amusement nowadays but I remember it being pretty frustrating at the time.

It sort of felt like, well, either you knew what the impact of unpublishing all your packages would be and you did it anyway, which makes you kind of antisocial, or you didn't know what the impact would be but did it anyway, which makes you kind of a hothead. And in this latest piece Azer has admitted that he didn't understand what the impact would be so... y'know... I do wonder if anger was at least a small factor.

Regardless, it's pretty clear that npm bear a lot of the responsibility for what happened. It's also something that happened a very long time ago and, as I've already implied, is just a funny story nowadays, not something I can manage any ire towards Azer over.

Re: Left-Pad (2024)

#47
post #20

Maintainer of a few top-10 npm packages here. This makes complete sense. Somewhere along the way NPM stopped being cooperative with the community. It cemented itself with the Microsoft acquisition, but was obvious quite a bit before that. There were so many cracks with how npm functioned, they weren't cooperating well with the community / mainline Node team, their push to commercial viability was really off-putting a…

It wasn’t the first package manager for a programming language and plenty of us pointed out the folly of packages that small. Npm (and JS in general) is a victim of fashion, primarily.

I think that statement is parsed as "npm was the first incredibly accessible package manager for [server-side JavaScript, which at the time was] an emergent popular technology,"

Re: Left-Pad (2024)

#48

Why Java can have reliable utility libraries such as Apache Commons and Google Guava, but JS somehow cannot?

Javascript does. lodash is/was pretty common. Most of the stuff as been absorbed into the standard library now.

Lodash has had pad/padStart/padEnd since 2016, 3 months before left-pad incident. https://lodash.info/doc/pad

Re: Left-Pad (2024)

#49
> Left-pad was like a "death" and "re-birth" moment for me. The part of me passionate about open-source was dead, and something new took over. Now, I'm passionate about business, marketing, running companies / teams

Wow, I couldn't think of a worse rebirth.

Re: Left-Pad (2024)

#50
post #16

It's a minor thing, but: > Most of my open source work followed Unix philosophy, so the packages did one thing at a time. Nobody has suggested that libc -- to take the most obvious example -- is against the Unix philosophy. Debates occur around whether whether commands / daemons do too much (recent poster child being systemd) or aren't composable.

The "unix philosophy" is a useless philosophy - perhaps worse than useless even - because "one thing" is not well defined, so in practice it adds nothing and just leads to arguments. You could say that Eclipse does "one thing" - being an IDE platform - but I don't think anyone thinks that's what the Unix devs meant. Similarly I don't think they meant for people to write libraries that contain one 11-line function. Th…

I feel like "do one thing and do it well" is an oversimplification:

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them

---

[1] https://archive.org/details/bstj57-6-1899/page/n3/mode/2up

Post reply on HN