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
Left-Pad (2024)
41–50 of 224 posts
Re: Left-Pad (2024)
#42Earlier 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.
Re: Left-Pad (2024)
#43Earlier 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).
Re: Left-Pad (2024)
#44Earlier 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).
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)
#45Azer 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…
Jon Schlinkert is a typical marketing A-hole. He should be banned from NPM and Github IMHO.
Re: Left-Pad (2024)
#46> 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)
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)
#47Maintainer 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.
Re: Left-Pad (2024)
#48Why Java can have reliable utility libraries such as Apache Commons and Google Guava, but JS somehow cannot?
Lodash has had pad/padStart/padEnd since 2016, 3 months before left-pad incident. https://lodash.info/doc/pad
Re: Left-Pad (2024)
#49Wow, I couldn't think of a worse rebirth.
Re: Left-Pad (2024)
#50It'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) 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