Left-Pad (2024)(azerkoculu.com)
azerkoculu.com
Left-Pad (2024)
https://azerkoculu.com/posts/left-pad
215 コメント
> On March 18, 2016, Isaac Z. Schlueter, the chief executive officer of npm, Inc., wrote to both Kik Interactive and Koçulu, stating that the ownership of the kik package would be manually transferred to Kik Interactive.
> After Koçulu expressed his disappointment with npm, Inc.'s decision and stated that he no longer wished to be part of the platform, Schlueter provided him with a command to delete all 273 modules that he had registered.[9] Koçulu executed the command on March 22, 2016, removing every package he had previously released
The author simply ran the script that NPM themselves told him to, and later NPM blamed the author for their own failings.
The author simply ran the script that NPM themselves told him to, and later NPM blamed the author for their own failings.
Ok fair! In that case I actually agree with his stance I think. I can understand how isaacs messed this up in what must've been a stressful situation, but it's hard to blame the author for it indeed, if he was just running the commands provided.
I mean if you’re the CEO of a package manager then you should probably have thought that one through a little bit more? Maybe ask one of the engineers what would happen?
Yeah indeed. Though I can appreciate the screwup. I mean, there was a heated thing going on, lawyers on one side and bad community PR on the other and NPM was caught in the middle. Couldnt backtrack on their maybe not so smart choice to give the "kik" package to Kik Messenger, and maybe hadn't thought through the consequences of encouraging the author to just delete all their packages. I disagree that that means they're "kids in suits" like some comments here suggest. It can just as well be an honest mistake made under pressure. People make mistakes sometimes! There's plenty precedence of mistakes by the NPM team but they also got a whole lot of stuff right!
But I do agree now that the author isn't really to blame.
But I do agree now that the author isn't really to blame.
For context, see https://en.wikipedia.org/wiki/Npm_left-pad_incident
11 lines of code! Wow. I had no idea it was that small.
There used to be the general wisdom of, "Don't re-invent the wheel. Let the hive-mind craft utility functions and use those because they'll be battle-hardened, well tested, and you can focus on your core business".
I think the left-pad incident helped shatter that myth. He we had huge packages depending on a package which padded a string in an inefficient manner.
It turns out that the many eyeballs of the bazaar had averted their gaze from what was actually happening, which is a system of impossible to audit dependency chains.
I think it also shows the impact of using a language with a poor standard library.
Padding is absolutely something that should be available as an extension over String.
If JavaScript were controlled in the same manner that Go, Rust, Java, .NET, python etc, then it would have been added years ago.
Apparently it has now finally arrived in ES2026: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I think the left-pad incident helped shatter that myth. He we had huge packages depending on a package which padded a string in an inefficient manner.
It turns out that the many eyeballs of the bazaar had averted their gaze from what was actually happening, which is a system of impossible to audit dependency chains.
I think it also shows the impact of using a language with a poor standard library.
Padding is absolutely something that should be available as an extension over String.
If JavaScript were controlled in the same manner that Go, Rust, Java, .NET, python etc, then it would have been added years ago.
Apparently it has now finally arrived in ES2026: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
On the flip side, I find that often python for example can go too far in the other directions with huge kitchen sink libraries that depend on other huge kitchen sink libraries. To the point where installing the most popular library for calculating the area of a 2D polygon requires installing a fast Fourier transform library. If you want a single quite simple image processing function, you're all of a sudden installing advanced graph algorithm and signal processing libraries.
> Apparently it has now finally arrived in ES2026
ES2017 [1]. The MDN docs always link the latest version of the spec; the year in the link doesn't correspond to the version where it was added. The proposal was already mostly done at the time of the incident [2]
[1] https://tc39.es/ecma262/2017/#sec-string.prototype.padstart [2] https://github.com/tc39/proposal-string-pad-start-end
ES2017 [1]. The MDN docs always link the latest version of the spec; the year in the link doesn't correspond to the version where it was added. The proposal was already mostly done at the time of the incident [2]
[1] https://tc39.es/ecma262/2017/#sec-string.prototype.padstart [2] https://github.com/tc39/proposal-string-pad-start-end
Oh, I see, sorry the "Specification" section is definitely misleading then by not also linking to the earliest specification it was included in.
> the left-pad incident helped shatter that myth
In what way? Have the dependency trees gotten significantly smaller since then?
In what way? Have the dependency trees gotten significantly smaller since then?
I don't think so, but at least awareness of dependencies as liabilities has increased.
I installed `pass` (the lightweight password manager) on a fresh headless system the other day and it brought in like 60 packages including a bunch of X stuff.
I installed `pass` (the lightweight password manager) on a fresh headless system the other day and it brought in like 60 packages including a bunch of X stuff.
Just checked on a fresh install of Fedora 42 "custom operating system" install, so pretty minimal. Didn't even check the "standard tools" box or whatever it's called.
Installing 'pass' pulled in: desktop-file-utils emacs-filesystem git-core libpng qrencode qrencode-libs
Plus weak (optional) dependencies: libwayland-client mailcap wl-clipboard xdg-utils
12 packages, 5 MB download, 24 MB installed. Could be worse, could be better.
I was honestly expecting Fedora to have less than that.
Installing 'pass' pulled in: desktop-file-utils emacs-filesystem git-core libpng qrencode qrencode-libs
Plus weak (optional) dependencies: libwayland-client mailcap wl-clipboard xdg-utils
12 packages, 5 MB download, 24 MB installed. Could be worse, could be better.
I was honestly expecting Fedora to have less than that.
On my particular (Ubuntu) system, `debtree pass` shows 301 dependencies (includes subdependencies) for a total install of 130 MB.
One of the big trigger is the dependency pass->xclip. That sets off a big cascade of X.
One of the big trigger is the dependency pass->xclip. That sets off a big cascade of X.
Inefficient? What would be an efficient way to do this? .Repeat() a string and then concatenate?
> Most of my open source work followed Unix philosophy, so the packages did one thing at a time. There was 350+ of them.
The man page for a unix binary is at least two orders of magnitude larger. At some point, the "Unix philosophy" doesn't make sense anymore. I mean, it couldn't even rightpad.
The man page for a unix binary is at least two orders of magnitude larger. At some point, the "Unix philosophy" doesn't make sense anymore. I mean, it couldn't even rightpad.
When the metadata for the package is larger than the source code you've probably gone too small!
packages like `left-pad` should really be named more like `resume-pad`
oh look at me, 589 published packages on npm! with 5 700 quadripillion weekly installs!
oh look at me, 589 published packages on npm! with 5 700 quadripillion weekly installs!
oh there are thousands of those out there on npm.
Short and trivial code.
Even if you do not use them at all in your own codebase
chances are quite high that some package you do use, uses
some of those tiny packages.
> NPM the company isn't curating NPM the registry
They do in fact curate the registry, mainly for reporting vulnerabilities to consumers and to remove malicious packages.
They do in fact curate the registry, mainly for reporting vulnerabilities to consumers and to remove malicious packages.
I'd probably call those things "maintenance" or "moderation" rather than "curation". Curation would imply they care about the quality, but in reality they just try to limit the damage of malicious packages.
Years ago I used Sourceforge and they had a policy you had to ask permission before deleting a project.
After left-pad, I understood why.
After left-pad, I understood why.
[deleted]
As someone who avoids javascript and its attendant ecosystem like its the Visual Basic plague of the 21st Century, the most interesting aspect of this whole story is the fact that Koçulu disconnected from the tech scene for some time, did some amazing hiking and camping and trail discovery, and now .. 8 years later .. still feels compelled to explain himself.
Technology is a fickle muse. We nerds obsess over her and degrade ourselves in her service, but she always calls us back into the light.
As someone who was around for the Morris worm and spent weeks negating its impact, I feel that there is a fundamental issue impacting our ability to make world-changing technology with the current tools. The less we strive to understand the organizational (ethical) failings of technology, the less technology can be used to effect productive change in the realms it is being applied.
That said, I'm about a month (and a few hundred failed compiles) away from taking my own sabbatical, and I can't help but try to reason what things would be like for me, upon my return after some years, in the technological space I've carved out for my own needs, at much different scales and contexts.
Perhaps it should become somewhat standard for us technologists to take sabbaticals, more often, and more seriously, in order to give us the context we need to understand the ethical dilemma that impinges upon our technological prowess.
Koçulu, thank you for your thoughts. I may never be effected by the javascript world, but the lessons it provides from within the temple nevertheless reverberate among the outer chambers ..
Technology is a fickle muse. We nerds obsess over her and degrade ourselves in her service, but she always calls us back into the light.
As someone who was around for the Morris worm and spent weeks negating its impact, I feel that there is a fundamental issue impacting our ability to make world-changing technology with the current tools. The less we strive to understand the organizational (ethical) failings of technology, the less technology can be used to effect productive change in the realms it is being applied.
That said, I'm about a month (and a few hundred failed compiles) away from taking my own sabbatical, and I can't help but try to reason what things would be like for me, upon my return after some years, in the technological space I've carved out for my own needs, at much different scales and contexts.
Perhaps it should become somewhat standard for us technologists to take sabbaticals, more often, and more seriously, in order to give us the context we need to understand the ethical dilemma that impinges upon our technological prowess.
Koçulu, thank you for your thoughts. I may never be effected by the javascript world, but the lessons it provides from within the temple nevertheless reverberate among the outer chambers ..
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.
> 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.
If anything, the left-pad debacle has shown that NPM package granularity has gone way too small, at a point where package overhead was outweighing the package simplicity benefits.
Left-pad was made at a time when tree-shaking wasn't really around, so it was good practice to only include the functions you needed to avoid making websites too heavy. If you just needed a small function then it'd be silly to include a huge utility library like Underscore.
You're missing the point. Nobody with a serious background in software development should ever need to pull in a package to pad a string or check if a number is even or odd. If someone is smart enough to use a package manager, they should be more than capable to write a function to pad a string (assuming the standard library doesn't include one already)!
How does serious background help the argument for wasting your time writing code that's already been written. By the way, why should serious people use padding from the standard library?
I would argue that a leftpad/is-odd package is the equivalent of writing a for loop. The time it cost you to search the internet, download the package, and rerun your build script cost more than the time to write the function from scratch and the behavior is indentical.
Duplicate code across the ecosystem is fine. Not every function must be unique for an entire programming language.
Duplicate code across the ecosystem is fine. Not every function must be unique for an entire programming language.
What about the time it cost you to search the internet, read the docs, and use the one from std? How many seconds does each variant take (with hot/cold memory cache?)
And the behavior could also be worse, there is no guarantee of perfection.
The last argument is too generic to offer any guidance. Why is it better for this function be duplicated?? Should it not be part of std to avoid uniqueness?
And the behavior could also be worse, there is no guarantee of perfection.
The last argument is too generic to offer any guidance. Why is it better for this function be duplicated?? Should it not be part of std to avoid uniqueness?
The standard library is a far less risky dependency than third-party libraries. It's far more reliable in presence and behavior.
While you are correct, the problem compounds when popular package developers choose to use tiny packages.
I don't need left-pad.
But maybe I need react-starter-kit.
Now, imagine that react-starter-kit has a dependency to markdown-js-blobber, which has a dependency to make-text-nice, which has a dependency to left-pad.
In this scenario I am now "pulling in a package to pad a string". If I am "smart enough to use a package manager", I should be "more than capable to write..." an alternative to react-starter-kit..?
I don't need left-pad.
But maybe I need react-starter-kit.
Now, imagine that react-starter-kit has a dependency to markdown-js-blobber, which has a dependency to make-text-nice, which has a dependency to left-pad.
In this scenario I am now "pulling in a package to pad a string". If I am "smart enough to use a package manager", I should be "more than capable to write..." an alternative to react-starter-kit..?
The onus there is on the "make-text-nice" developer, not an eventual user of "make-text-nice".
I don't place any blame here on the person using `react-starter-kit` and I think you're being a bit obtuse to suggest otherwise. It's the original person who pulled in a package for <10 lines of code who is to blame.
I provided the real reason for the high download counts of these packages.
However, JavaScript never had a proper standard library.
Combine this to mainstream education teaching that you should always reuse code when possible instead of "reinventing the wheel", and web shops agreeing to it because "using libraries saves time", and it's easy to understand the "popularity" of left-pad.
To a certain extent, and to the best of my knowledge, those things haven't really changed.
Combine this to mainstream education teaching that you should always reuse code when possible instead of "reinventing the wheel", and web shops agreeing to it because "using libraries saves time", and it's easy to understand the "popularity" of left-pad.
To a certain extent, and to the best of my knowledge, those things haven't really changed.
Ironically I feel like this is something LLMs will improve. Now anyone can type "create left pad function" and it will essentially just vendor in the existing code.
What does the size or granularity have to do with the incident? If the author had combined all his 350+ packages into one (or had had a more comprehensive text-utils.js package) and pulled that instead, the issue would have been at least as severe?
I don’t think such small packages are sensible, in particular when versioned separately, but I also don’t see how the left-pad debacle has shown that.
I don’t think such small packages are sensible, in particular when versioned separately, but I also don’t see how the left-pad debacle has shown that.
baobabKoodaa(1)
> Nobody has suggested that libc -- to take the most obvious example -- is against the Unix philosophy.
Plenty of people have suggested that. I'll suggest it for you now if you like. The modern form of libc is very much against the unix philosophy; traditional Unix had a much simpler libc where many functions were just syscalls; some parts of today's libc were hived off into separate libraries like libm, and other parts like NSS and convoluted DNS resolution frameworks just didn't exist at all.
Plenty of people have suggested that. I'll suggest it for you now if you like. The modern form of libc is very much against the unix philosophy; traditional Unix had a much simpler libc where many functions were just syscalls; some parts of today's libc were hived off into separate libraries like libm, and other parts like NSS and convoluted DNS resolution frameworks just didn't exist at all.
The obverse to 'do one thing' is that you have to do the whole thing.
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.
The actual advice should be something like "programs/libraries shouldn't try to do too much or too little". How do you know how much is too much or too little? Like so many programming guidelines the answer is you need taste and experience.
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.
The actual advice should be something like "programs/libraries shouldn't try to do too much or too little". How do you know how much is too much or too little? Like so many programming guidelines the answer is you need taste and experience.
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
(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
I agree with that. And like most rule of thumbs, it's very useful to go beyond the prescriptive part and ask yourself "why". And as qsort described, doing "one thing well" enables you to have desirable traits (easy testability, low cost refactoring, etc.).
> because "one thing" is not well defined
That's what a philosophy is, gives you some general guideline and you have to use your thinking to figure out how to apply it in specific circumstances. It does not substitute that thinking neither does it prevent stupid choices, it helps guide you in a higher/strategic level. It is not responsible for people making stupid decisions.
That's what a philosophy is, gives you some general guideline and you have to use your thinking to figure out how to apply it in specific circumstances. It does not substitute that thinking neither does it prevent stupid choices, it helps guide you in a higher/strategic level. It is not responsible for people making stupid decisions.
Sure but my point is that the Unix philosophy is so ambiguous that it leads to more confusion than it helps.
Stating it in a way that makes the ambiguity obvious - "don't make your program do too much" - reveals how little value it contains.
Stating it in a way that makes the ambiguity obvious - "don't make your program do too much" - reveals how little value it contains.
If you consider it from the point of view of how "clear is the scope?" Then it makes more sense.
Libc implementations have a very clear scope, clear enough that you can point to the specification. That is their 'one thing' do what that spec says.
Eclipse however, doesn't have that singular goal. You would be hard pressed to say how many of Eclipse's tentacles is a clear push towards being an ide. What should a completely finished version of Eclipse that met all it's goals look like?
Similarly the one thing could be "be a c preprocessor" or be a full "c compiler" these are both "one thing"s even while one is a subset of the other.
The intention of "do one thing, and do it well" is not to limit the scope but to show the boundary of the scope and to commit to doing everything within that boundary
By making your one thing "a full c compiler" you should be committing to doing everything that someone making a c preprocessor is doing, and to the same standard. The Unix philosophy should be considered a warning not to neglect components because you are working on a larger system.
You can't do everything, but you don't have to. If others are following the same principles then many of the parts of what you need will be done to a high standard by others.
Libc implementations have a very clear scope, clear enough that you can point to the specification. That is their 'one thing' do what that spec says.
Eclipse however, doesn't have that singular goal. You would be hard pressed to say how many of Eclipse's tentacles is a clear push towards being an ide. What should a completely finished version of Eclipse that met all it's goals look like?
Similarly the one thing could be "be a c preprocessor" or be a full "c compiler" these are both "one thing"s even while one is a subset of the other.
The intention of "do one thing, and do it well" is not to limit the scope but to show the boundary of the scope and to commit to doing everything within that boundary
By making your one thing "a full c compiler" you should be committing to doing everything that someone making a c preprocessor is doing, and to the same standard. The Unix philosophy should be considered a warning not to neglect components because you are working on a larger system.
You can't do everything, but you don't have to. If others are following the same principles then many of the parts of what you need will be done to a high standard by others.
> Libc implementations have a very clear scope, clear enough that you can point to the specification. That is their 'one thing' do what that spec says.
No you can't get out of it my just saying the "one thing" is to do what the spec says. Who decided what's in the spec?
Would Eclipse be fine if someone just wrote a spec for it?
No you can't get out of it my just saying the "one thing" is to do what the spec says. Who decided what's in the spec?
Would Eclipse be fine if someone just wrote a spec for it?
It doesn't matter who decided what's in the spec. What matters is that you decided to implement it to a high standard. It's usefulness to others will be related to what they think of the spec. Nobody has to use your tool, but it's good for everyone to know exactly what the tool is.
Eclipse would be fine if it had a spec, committing to implementing that might be a task to arduous for some. A full spec would also lay bare what its goal is. Which in turn might lead to people deciding the tool they need is not this one. But yes, if was clear what it should be doing and it did that well then everyone benefits.
Eclipse would be fine if it had a spec, committing to implementing that might be a task to arduous for some. A full spec would also lay bare what its goal is. Which in turn might lead to people deciding the tool they need is not this one. But yes, if was clear what it should be doing and it did that well then everyone benefits.
So the Unix philosophy doesn't apply if you have a written specification for you program? That's a pretty out-there view. I don't see why having a spec is related to what the Unix philosophy is trying to achieve.
[deleted]
The Unix philosophy tells you how to get a powerful interactive programming environment on a 16-bit minicomputer where the maximum text segment size was 64KiB. The libc I'm using on this cellphone is 1MiB, 16× bigger. So at least 90% of libc is against the Unix philosophy.
I don't see how anyone could read the Lions book or APUE, on one hand, and the pthreads manual or the ANSI C specification of setlocale(), on the other, and come to the conclusion that they represent the same philosophy. It's like thinking Ayn Rand is an exponent of the same philosophy as Epicurus; it betrays a staggering lack of sincere engagement with either one.
I don't see how anyone could read the Lions book or APUE, on one hand, and the pthreads manual or the ANSI C specification of setlocale(), on the other, and come to the conclusion that they represent the same philosophy. It's like thinking Ayn Rand is an exponent of the same philosophy as Epicurus; it betrays a staggering lack of sincere engagement with either one.
[deleted]
Thank you for writing this akoculu.
I remember the incident and what stuck me most is how, for me, this was a clear example of a community (Javascript) that depended too much on dependencies (pun somewhat intended)
I don't know why so many people put so much blame on you. You unpublished a package with 11 lines of code [0]. I don't think you fully understood the frustration it would cause. And you mentioned that in the post.
> NPM didn't show usage stats, and there was almost no activity on Github. As a user, it was impossible to know the impact of unpublishing packages
The root cause imo isn't akoculu unpublishing the package. In my opinion that lies more in the over-reliance on dependencies, the npm policies and maybe also build systems not caching/vendoring code.
[0] https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou...
I remember the incident and what stuck me most is how, for me, this was a clear example of a community (Javascript) that depended too much on dependencies (pun somewhat intended)
I don't know why so many people put so much blame on you. You unpublished a package with 11 lines of code [0]. I don't think you fully understood the frustration it would cause. And you mentioned that in the post.
> NPM didn't show usage stats, and there was almost no activity on Github. As a user, it was impossible to know the impact of unpublishing packages
The root cause imo isn't akoculu unpublishing the package. In my opinion that lies more in the over-reliance on dependencies, the npm policies and maybe also build systems not caching/vendoring code.
[0] https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou...
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 projects that actually use them. Here is the deal: Do you want to be trolled? Then use handlebars-helpers, if not, then stop using the damn library.
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 projects that actually use them. Here is the deal: Do you want to be trolled? Then use handlebars-helpers, if not, then stop using the damn library.
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.
Jon Schlinkert is a typical marketing A-hole. He should be banned from NPM and Github IMHO.
The version history of the kik package[0] is odd. It has been replaced with a security holding package nine years ago[1].
[0] https://www.npmjs.com/package/kik?activeTab=versions
[0] https://www.npmjs.com/package/kik?activeTab=versions
I think this is the biggest irony of it: the kik package, which kik where so desperate to have, is basically sweet Fanny Adams.
Also, Kik turn out to be negligent and pretty scummy. There was some controversy with them involving crypto, but the main thing I remember about them is that Kik is rife in terms of trading pornography, including child pornography, as discussed on this Darknet Diaries episode: https://darknetdiaries.com/episode/93/.
So, from that point of view, I quite enjoy that Azer Koçulu told them to fuck off.
Also, Kik turn out to be negligent and pretty scummy. There was some controversy with them involving crypto, but the main thing I remember about them is that Kik is rife in terms of trading pornography, including child pornography, as discussed on this Darknet Diaries episode: https://darknetdiaries.com/episode/93/.
So, from that point of view, I quite enjoy that Azer Koçulu told them to fuck off.
>Also, Kik turn out to be negligent and pretty scummy.
turns out?
they threatened a pre-existing naming collision with legal action and bullied the platform first into forcing the name to be theirs, and then afterwards by crying to npm until their software tests passed again.
they began scummy.
turns out?
they threatened a pre-existing naming collision with legal action and bullied the platform first into forcing the name to be theirs, and then afterwards by crying to npm until their software tests passed again.
they began scummy.
Yeah, but this also happened to a colleague of mine who created the pug templating package. It's so long ago now that I forget what it was originally called but, basically, he'd chosen a name that infringed somebody else's trademark. I'm not a trademark law expert but the thing about trademarks is they have to be defended or the holder can lose the exclusivity of the mark.
So my friend sensibly caved in and changed the name of the package, got on with his life, and now it's all long forgotten history.
Going back to Kik, before I knew about all the other stuff (which I only found out about when I listened to that Darknet Diaries episode last year - bit late to the party there) I simply thought they'd gone about defending their trademark in a hamfisted and douchey way that had got Azer's back up. Lawyer's gonna lawyer, and the way they did it I thought they were douchebags, but beyond that I didn't give it much consideration. There was certainly no way any of this even hinted to me that they were negligently facilitating the distribution of child porn[0].
[0] Yes, this is obviously against Kik's ToS, but ToS are only worth anything if they're enforced whereas - certainly at times prior to the Darknet Diaries episode being released in 2021 - there was at best inconsistent and ineffective enforcement of these terms. I have no insight into the current situation with Kik.
So my friend sensibly caved in and changed the name of the package, got on with his life, and now it's all long forgotten history.
Going back to Kik, before I knew about all the other stuff (which I only found out about when I listened to that Darknet Diaries episode last year - bit late to the party there) I simply thought they'd gone about defending their trademark in a hamfisted and douchey way that had got Azer's back up. Lawyer's gonna lawyer, and the way they did it I thought they were douchebags, but beyond that I didn't give it much consideration. There was certainly no way any of this even hinted to me that they were negligently facilitating the distribution of child porn[0].
[0] Yes, this is obviously against Kik's ToS, but ToS are only worth anything if they're enforced whereas - certainly at times prior to the Darknet Diaries episode being released in 2021 - there was at best inconsistent and ineffective enforcement of these terms. I have no insight into the current situation with Kik.
>pug templating package. It's so long ago now that I forget what it was originally called
jade, iirc. still best html/xml/etc templating package out there, jsx/tsx can't compare
jade, iirc. still best html/xml/etc templating package out there, jsx/tsx can't compare
Yes! Thank you! That was it. I still use pug in a side project because it works really well and would just be way too much hassle to untangle and migrate.
I just looked jade up on npm and it's still there, so the company that wanted Forbes to change the name didn't even want to publish a package by the looks of it.
I just looked jade up on npm and it's still there, so the company that wanted Forbes to change the name didn't even want to publish a package by the looks of it.
haha, so, all of this for… nothing in the end?
The kik user page almost says it all.
https://www.npmjs.com/~kikinteractive
One person in the company thought this would be cool to be on NPM, then ... the lpad story.
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"
I remember part of the discourse being that this was a much needed wake up call to web-devs for their relentless reliance on micro packages like left-pad. Part of it was the culture of publishing packages for the sake of popularity and github stars. Part of it were also devs insisting that implementing anything that could otherwise be installed through NPM was "reinventing the wheel". Today I work with a lot of devs who still prefer using micro packages, regardless of their simplicity, because to them it means "less maintenance". Go figure.
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
[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?)
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?)
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.
"The compiler will take care of it", funny, heard that one before, I'd profile it just to be on the safe side...
I didn't mean that. JS doesn't have any lower-level interface for handling memory, so such optimization has to be in the implementation. It should be quite obvious that relying on such optimization can be problematic.
The line `str = ch + str` is itself a linear-time operation, with time proportional to the length of the new string.
That linear-time operation is then additionally repeated `len` times
That linear-time operation is then additionally repeated `len` times
[deleted]
Really, what's the qualitative difference between reaching for a utility function that someone else already wrote within your project and reaching for a package that someone else already published within your ecosystem? They're obviously not the same thing but are they so far apart that you can't wrap your head around it wanting to treat them the same, given sufficiently advanced tooling?
The utility function just has to fit your use case, and can be easily refactored as it lives in a local context.
The package has to have a public API, meet millions of different people's use cases, and any change to the API will cause millions of man-hours of useless work... and yet if it's a poorly designed API, it might cause millions of sub-optimal programs.
Every project has a StringUtils file. But every project's StringUtils file is different.
Published packages in an ecosystem ought to be well-designed, with good performance, good APIs, good security. Packages that don't meet that bar ought to be kept out. npm is jarring because it let any old shit get published, despite there being long-standing package ecosystems in other languages with much better standards, that they could have copied from (CPAN, PyPi, RubyGems, Maven Central, NuGet Gallery, etc.)
The package has to have a public API, meet millions of different people's use cases, and any change to the API will cause millions of man-hours of useless work... and yet if it's a poorly designed API, it might cause millions of sub-optimal programs.
Every project has a StringUtils file. But every project's StringUtils file is different.
Published packages in an ecosystem ought to be well-designed, with good performance, good APIs, good security. Packages that don't meet that bar ought to be kept out. npm is jarring because it let any old shit get published, despite there being long-standing package ecosystems in other languages with much better standards, that they could have copied from (CPAN, PyPi, RubyGems, Maven Central, NuGet Gallery, etc.)
The number of distinct entities in your supply chain and whether those developers are on your payroll.
As a business, each additional human or company you add to your supply chain represents additional risk that you're taking on. You can go some ways towards mitigating those risks—one of the most common is to sign a contract with them rather than doing business ad hoc—but the risk doesn't go away entirely. Given that additional risk for each additional downstream supplier, it's generally safer to use code written by someone who's already on your payroll than it is to use code written by someone you've never met and have no way of vetting.
As a business, each additional human or company you add to your supply chain represents additional risk that you're taking on. You can go some ways towards mitigating those risks—one of the most common is to sign a contract with them rather than doing business ad hoc—but the risk doesn't go away entirely. Given that additional risk for each additional downstream supplier, it's generally safer to use code written by someone who's already on your payroll than it is to use code written by someone you've never met and have no way of vetting.
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
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...
maximum code reuse flex, copy-paste is for losers.
The biggest reason for this is reuse between libraries - if you use 10 libraries, you don't want each of them to add its own leftpad. This is especially a problem if this happens in client code and you then send duplicate code to the browser.
Muh Unix way.
> On the NPM side, I observed general condescending attitude towards developers, which led them make series of unreasonable decisions and ultimately blame me for all the cost.
NPM has not really learned much in the time since this event either.
NPM has not really learned much in the time since this event either.
It was good that this happened. Name squatting is a real problem and when in doubt, err on the side of least surprise. Not having usage statistics was a real problem. Being able to just unpublish was a real problem. Infrastructure relying on trivial 10-liners by opinionated individuals was (and still is) a real problem. Nobody in this situation is truly at fault, because nobody owes anyone anything, yet everyone can learn something from it.
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 and forced, and many of the team members had a somewhat rough reputation.
Indeed I visited the offices in Oakland (if I recall correctly), and had an... interesting set of interactions there, not particularly positive, that I'll keep to myself.
The unpublish hole was well known at the time. Everyone blamed left-pad for breaking the internet, as it were, but nobody seemed to come down on npm for the sheer mismanagement of it all.
If memory serves they forcefully reinstated the package against the maintainer's wishes, which is a divorcement from the people they claimed to serve at best, and legally dubious at worst. Shortly after this they stopped caring much at all about abuse on their platform at all (core.js advertisement spam, anyone?) and haven't really worked with the community on standards, compatibility, etc. after that.
The npm@5 release was a disaster. The introduction of package lock files couldn't have gone worse, and as I remember it it was a push to get it out alongside the next Node.js major release (I got the feeling the Node team didn't wait for npm to be ready, which I think is a good thing given npm is a for-profit, or at least acts like one).
The community outreach during that time of what seemed like endless major, catastrophic bugs and the shaming of the community for putting pressure on them, the pious attitude, was only further proof that npm was no longer an agent of FOSS. I can't remember if left-pad came before or after that but in my head it was all one long drawn out declination of the ecosystem.
The packages on npm are a meme now; small packages that do trivial tasks, and everyone likes to make fun of it. Maybe it wasn't the best thing, in hindsight. But context is crucial; npm was the first incredibly accessible package manager for an emergent popular technology, almost entirely community managed, with a good system for querying and tight integration with Github's "social coding" spirit.
It existed very early in the Node lifetime, back before even ES5 was available (we still used `var` and `prototype`!), before JavaScript best practices really existed. Before Node.js was given to the community by Joyent. Before even the Io.js fork and the exit from the long stagnation that was Node 0.10/0.12.
Nobody knew the best way to do things.
I can completely understand the author. From a security perspective I'm really thankful left-pad happened, even if it wasn't the reasoning of the author; it made people acutely aware of what relying on corporate interests divested from the communities they claim to serve, bring to the table in terms of risk. It started many conversations about supply chain security, redundancy, etc. That's a hard thing to do, and it's made the industry a bit better in the long run.
Good followup, neat to read this after so long.
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 and forced, and many of the team members had a somewhat rough reputation.
Indeed I visited the offices in Oakland (if I recall correctly), and had an... interesting set of interactions there, not particularly positive, that I'll keep to myself.
The unpublish hole was well known at the time. Everyone blamed left-pad for breaking the internet, as it were, but nobody seemed to come down on npm for the sheer mismanagement of it all.
If memory serves they forcefully reinstated the package against the maintainer's wishes, which is a divorcement from the people they claimed to serve at best, and legally dubious at worst. Shortly after this they stopped caring much at all about abuse on their platform at all (core.js advertisement spam, anyone?) and haven't really worked with the community on standards, compatibility, etc. after that.
The npm@5 release was a disaster. The introduction of package lock files couldn't have gone worse, and as I remember it it was a push to get it out alongside the next Node.js major release (I got the feeling the Node team didn't wait for npm to be ready, which I think is a good thing given npm is a for-profit, or at least acts like one).
The community outreach during that time of what seemed like endless major, catastrophic bugs and the shaming of the community for putting pressure on them, the pious attitude, was only further proof that npm was no longer an agent of FOSS. I can't remember if left-pad came before or after that but in my head it was all one long drawn out declination of the ecosystem.
The packages on npm are a meme now; small packages that do trivial tasks, and everyone likes to make fun of it. Maybe it wasn't the best thing, in hindsight. But context is crucial; npm was the first incredibly accessible package manager for an emergent popular technology, almost entirely community managed, with a good system for querying and tight integration with Github's "social coding" spirit.
It existed very early in the Node lifetime, back before even ES5 was available (we still used `var` and `prototype`!), before JavaScript best practices really existed. Before Node.js was given to the community by Joyent. Before even the Io.js fork and the exit from the long stagnation that was Node 0.10/0.12.
Nobody knew the best way to do things.
I can completely understand the author. From a security perspective I'm really thankful left-pad happened, even if it wasn't the reasoning of the author; it made people acutely aware of what relying on corporate interests divested from the communities they claim to serve, bring to the table in terms of risk. It started many conversations about supply chain security, redundancy, etc. That's a hard thing to do, and it's made the industry a bit better in the long run.
Good followup, neat to read this after so long.
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.
Npm (and JS in general) is a victim of fashion, primarily.
That isn't what I was claiming. I was drawing attention to it being super early on in an ecosystem, in an industry where lots of the "package manager best practices" are now formed based on Node's small-package qualms.
Unix philosophy is "do one thing, do it well". Left-Pad forgot about the second part.
For me it was surprising that so many projects used this naive implementation. Nonnaive implementation is faster and much smaller.
For me it was surprising that so many projects used this naive implementation. Nonnaive implementation is faster and much smaller.
I'm going to preface this with "I'm not sure if the culture is still there, nor do I develop JavaScript" ... so I'm writing about something I remember reading.
People are after the "number of downloads" metric on npm for various reasons. Left-pad has 1.4 million weekly downloads https://www.npmjs.com/package/left-pad Is-even has 160k weekly downloads https://www.npmjs.com/package/is-even
Sometimes people will include it as a dependency as a joke in their useful library. Other times the people who write these put it in useful libraries that they contribute to so that use of the useful boosts their numbers. I'm forgetting where it is now, but it was one of the big foundational libraries in React that used one of those and there was resistance to replacing (I believe) an include and use of is-even because they were a very strict adherent to the "never write code you can include" which meant that everything using it included it.
One such story: Why has there been nearly 3 million installs of is-odd - npm in the last 7 days? - https://www.reddit.com/r/programming/comments/886zji/why_has...
People are after the "number of downloads" metric on npm for various reasons. Left-pad has 1.4 million weekly downloads https://www.npmjs.com/package/left-pad Is-even has 160k weekly downloads https://www.npmjs.com/package/is-even
Sometimes people will include it as a dependency as a joke in their useful library. Other times the people who write these put it in useful libraries that they contribute to so that use of the useful boosts their numbers. I'm forgetting where it is now, but it was one of the big foundational libraries in React that used one of those and there was resistance to replacing (I believe) an include and use of is-even because they were a very strict adherent to the "never write code you can include" which meant that everything using it included it.
One such story: Why has there been nearly 3 million installs of is-odd - npm in the last 7 days? - https://www.reddit.com/r/programming/comments/886zji/why_has...
what would that nonnaive implementation look like?
Relevant discussion from the time left-pad incident happened
- https://news.ycombinator.com/item?id=11349870
- https://news.ycombinator.com/item?id=11349870
To me it is very strange how many companies do not internally mirror every single dependency of their builds. You should be able to do a clean build fully offline (and not count on luck with the download caches).
Include them as git submodule and you have that for free.
Yep.
I vendor dependencies on the projects I work.
Predictable, offline builds. Storage is cheap.
I vendor dependencies on the projects I work.
Predictable, offline builds. Storage is cheap.
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
Lodash has had pad/padStart/padEnd since 2016, 3 months before left-pad incident. https://lodash.info/doc/pad
In decreasing order of importance: culture, a good standard library, and tooling that pushes you to be deliberate about your dependencies rather than dumping 300 stupid packages inside every project.
Maven is incredibly well designed (and ironically gets nothing but hate for it), it's probably the hidden reason Java is so successful.
Why does Maven exist, without the commercial compromises of NPM? Probably because Java has the well-funded, well-supported, but non-profit and community-oriented Apache foundation, which is something extremely rare and precious (and probably at least partly a lucky result of Java's complicated legal history).
(JS has plenty of great utility libraries. The problem is that its package management is excessively centralised and not managed terribly well)
Why does Maven exist, without the commercial compromises of NPM? Probably because Java has the well-funded, well-supported, but non-profit and community-oriented Apache foundation, which is something extremely rare and precious (and probably at least partly a lucky result of Java's complicated legal history).
(JS has plenty of great utility libraries. The problem is that its package management is excessively centralised and not managed terribly well)
The operators of Maven Central deserve a lot of credit for their good stewardship. Unlike the NPM registry, Maven Central does not permit anyone to unpublish packages. Unlike the NPM registry, Maven Central requires verification of domain or forge account ownership to claim a namespace. These are good practices, and anyone seeking to create a central package registry would do well to at least consider this. Maven Central is currently operated by SonaType, but it has changed hands a few times. This article covers its history: https://www.sonatype.com/blog/the-history-of-maven-central-a...
Additionally, it is standard practice in the Java world, which is more "corporate" or "enterprise-y", for better and for worse, to have organisations operate their own internal package registries / mirrors. Even if you unpublished a major package from Maven Central, many organisations would be completely unaffected because they retain archived copies of all of their dependencies.
Additionally, it is standard practice in the Java world, which is more "corporate" or "enterprise-y", for better and for worse, to have organisations operate their own internal package registries / mirrors. Even if you unpublished a major package from Maven Central, many organisations would be completely unaffected because they retain archived copies of all of their dependencies.
All that is true, but I think the fact that Maven has supported multiple repos and proxy repos for decades is a significant factor. SonaType deserve credit for being good stewards, but it's also relevant that they have had real competition (e.g. jFrog ran a similar public repository until recently) and if they did ever behave badly then for many organisations it would be a 1-line change in their Maven config to switch, which creates rather different dynamics compared to NP, PyPi etc..
[deleted]
Google guava is more like lodash than like leftpad
<snip, i got my history wrong>
Arguably the root problem was lack of user namespacing; the incident would have been less likely to happen in the first place if the packages in question were named "~akoculu/left-pad" and "~akoculu/kik".
That's right and probably a lot less people would have used left-pad because it looks like a package for a specific org.
It used to. Jquery and Underscore basically filled that role for years.
I remember this incident and it is one of many reasons I was turned off by the entire JS ecosystem.
How come this is related to JS only? Like, if I own a python/rust/go/whatever public package named XYZ and later a company named XYZ forces me to release the package because of trademark issues, and I cannot do but obey, all my packages may run the same luck, so anybody relying on them would be screwed.
I don’t see how the size of the package matters here.
I don’t see how the size of the package matters here.
To your point, in JVM the convention is to package based on domain name so you don't have this type of issue.
But I think the GP's point is that the cultural in other ecosystems didn't lean as heavily into "there's a package for that®" as JS does
But I think the GP's point is that the cultural in other ecosystems didn't lean as heavily into "there's a package for that®" as JS does
I think the issue is that JS force you to have hundreds, or even thousands, dependencies. Python and other language have a richer std library and more "general purpose" packages, so the total number of dependencies is lower.
I owned the heroku user name on npm and gave it to official heroku website upon request.
That's so cool actually! Did you ask for any compensation? Short "iconic" usernames are kinda rare
my compensation is the story I can tell people like this.
[deleted]
[deleted]
A closer look at the sequence of events makes it clear that the failures weren’t due to the package author.
He fulfilled his responsibilities as a author.
He fulfilled his responsibilities as a author.
[deleted]
I never got why people were so mad at the guy behind left-pad. The entire incident showcases the sheer lunacy behind common web frameworks, and the power and control they sacrificed for the ease of use of external dependencies. If your day is ruined because some random guy you've never heard of on the other side of the world got an angry letter from lawyers, maybe take a look at the house of cards your product is based on rather than lay down blame.
left-pad will happen again. Maybe not on NPM, but on crates.io/pypi/Google's go proxy. All it takes is for a developer to join the ICC and piss of Trump and suddenly the code is impossible to find on any of the standard repositories. Even Go will have issues because despite the Github references, all the standard go traffic still goes through Google. Or even worse, someone fights back against a recent invasion and uploads a virus that wipes the drive of whatever locale they're targeting.
left-pad will happen again. Maybe not on NPM, but on crates.io/pypi/Google's go proxy. All it takes is for a developer to join the ICC and piss of Trump and suddenly the code is impossible to find on any of the standard repositories. Even Go will have issues because despite the Github references, all the standard go traffic still goes through Google. Or even worse, someone fights back against a recent invasion and uploads a virus that wipes the drive of whatever locale they're targeting.
> 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.
Wow, I couldn't think of a worse rebirth.
Because those things don’t align with what you value? Of course.
Do you think the world is better off with this guy going from FOSS passion to "business & marketing passion"?
I understand if your values contain something like "money for me is good", but do your values also contain something like "money for this random guy is good"?
I understand if your values contain something like "money for me is good", but do your values also contain something like "money for this random guy is good"?
Why does this guy owe anything to the world? This comment drips with entitlement.
Business & marketing are alignment mechanisms: to a first approximation, the closer you are to what people value, the more money you make, and that money is a signal that you're doing it right.
Like all alignment mechanisms (democracy, bureaucracy, etc.), these things only works to a first approximation — but they do work to a first approximation.
Making stuff (FOSS or otherwise) without caring about your audience leads to things like TempleOS, or the novel I've yet to finish writing (I'm never happy with what I've done despite having started it a decade ago already).
Like all alignment mechanisms (democracy, bureaucracy, etc.), these things only works to a first approximation — but they do work to a first approximation.
Making stuff (FOSS or otherwise) without caring about your audience leads to things like TempleOS, or the novel I've yet to finish writing (I'm never happy with what I've done despite having started it a decade ago already).
I strongly doubt that people who claim to, all of a sudden, be passionate about marketing or business are driven by the noble impulse of value creation that you're describing. Rather, this is more of a positive externality of chasing wealth or status, where "passion" is used as a pro-social facade to frame greed. That is not to say that all business is motivated by profit alone, but something just doesn't add up in the OOP's narrative.
Yes, I think a passion about marketing can only result in net-negative for humanity.
It's not that I don't value those things, it's that I think they're actively harmful (at least some of them), and that being passionate about them shows very toxic personality traits.
It's not that I don't value those things, it's that I think they're actively harmful (at least some of them), and that being passionate about them shows very toxic personality traits.
I agree completely, but would say the same of your username.
Check this discussion: https://news.ycombinator.com/item?id=43867827
Responding to client requests can be nice, sure, but having to be available outside working hours is still awful, and that's the defining characteristic of what people usually mean by oncall.
I agree, but iLoveOncallTasksButNotTheHours doesn't have the same ring to it.
[deleted]
> 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)
It's because you haven't read al-Ghazali yet.
(definitely the most pompous and self-important part of this post)
When was the last time you were threatened (“we’ll will bang on your door and take down your accounts”) by a company like Kik and you defended the principles and values you believed until the end?
I’m quite familiar with both western and eastern traditions, don’t know any better source than Ghazali’s “the alchemy of happiness” about how people make decisions.
It’s kind of ironic to see people being triggered by just the mention of it though — just reflects what your heart tends to reject impulsively. I wish you curiosity.
P.S Here’s the full quote, it entertainingly describes the ignorance here:
“first, they didn't look at the dates of the emails. They don't understand the timeline.
second, they can't relate to standing your ground in a high pressure situation involving threats.
and third, they haven't read Al-Ghazali yet, don't quite understand how (free) people make decisions”
I’m quite familiar with both western and eastern traditions, don’t know any better source than Ghazali’s “the alchemy of happiness” about how people make decisions.
It’s kind of ironic to see people being triggered by just the mention of it though — just reflects what your heart tends to reject impulsively. I wish you curiosity.
P.S Here’s the full quote, it entertainingly describes the ignorance here:
“first, they didn't look at the dates of the emails. They don't understand the timeline.
second, they can't relate to standing your ground in a high pressure situation involving threats.
and third, they haven't read Al-Ghazali yet, don't quite understand how (free) people make decisions”
[flagged]
They are citing something which changed their life significantly, and leaving pointers to the same thing if you're interested (or need further explanation).
If getting wisdom from others is not your thing, I can respect that, but low-key insulting them for leaving you pointers for a more enlightened place is rude.
You can instead say "I don't understand why Al-Ghazali relates to this", and that would be completely OK.
If getting wisdom from others is not your thing, I can respect that, but low-key insulting them for leaving you pointers for a more enlightened place is rude.
You can instead say "I don't understand why Al-Ghazali relates to this", and that would be completely OK.
The author made an implicit assumption, and you're making the same one, that they're filled with wisdom received straight from al-Ghazali. Firstly, only wankers act like they're wise and their audience isn't. Secondly, they said "haven't read al-Ghazali yet", implying that it's only a matter of time before everyone reads him.
Lastly, it's fine to quote someone but you need to explain how it's relevant to the conversation. The author could have summarised al-Ghazali's idea about free will or whatever and it would have been fine. But he didn't even bother, as if the ideas so basic and well known that it's not even worth doing.
I'm pretty comfortable with the way I've poked fun at the author's pompousness. If you need further explanation it's because you haven't read Chanakya yet.
Lastly, it's fine to quote someone but you need to explain how it's relevant to the conversation. The author could have summarised al-Ghazali's idea about free will or whatever and it would have been fine. But he didn't even bother, as if the ideas so basic and well known that it's not even worth doing.
I'm pretty comfortable with the way I've poked fun at the author's pompousness. If you need further explanation it's because you haven't read Chanakya yet.
I'll read Chanakya, but I don't see how he's supposed to appease to your taste and style of writing.
I don't think that you're pompous because you cited somebody I don't know that existed. I'm not a god. People show me things I don't know, I take note of them.
Maybe I won't agree with the direction you show me, but at least I have a new direction to discover.
This is the difference.
I don't think that you're pompous because you cited somebody I don't know that existed. I'm not a god. People show me things I don't know, I take note of them.
Maybe I won't agree with the direction you show me, but at least I have a new direction to discover.
This is the difference.
Fwiw I don't completely agree with you but I appreciate your enthusiasm for the word "wanker" in this thread.
akoculu(1)
And surely you read Ghazali and know what you’re talking about.
Why does it make him sound like a wanker? That’s a very uncharitable reading for no particular reason.
[flagged]
[deleted]
Let's consider an example about a tangible phenomena: Gaussian Integration, Quantum Entanglement, Crystalline Structure Formation in Alloyed Metals with Heat Treatment, Combustion Dynamics in a Gasoline Engine, etc.
Let's put the same sentence:
"I'd love to explain to you, but if you haven't read $SOURCE_MATERIAL, you wouldn't understand it anyway".
Does it sound pompous and insufferable?
Let's put the same sentence:
"I'd love to explain to you, but if you haven't read $SOURCE_MATERIAL, you wouldn't understand it anyway".
Does it sound pompous and insufferable?
Look mate you're a fan of this writing, that's fine. I respect your opinion. Let's agree to disagree.
I'm not a fan, but accept them as they are.
Of course we can agree to disagree. I'm not trying to win anything, but just express my perspective.
Have a nice day!
Politely pushes forward a freshly brewed mug of tea across the counter.
Of course we can agree to disagree. I'm not trying to win anything, but just express my perspective.
Have a nice day!
Politely pushes forward a freshly brewed mug of tea across the counter.
i haven't read it, now i'm interested in it, and frankly you sound like much more of a "wanker" at the end of things for centering your own (lack of) experience in this discussion.
Given that this post is meant to explain your perspective at the time, I think it would make sense to explain it at least a little. At the very least, I am curious. What does Al-Ghazali have to say about making decisions that influenced you? I have not read Al-Ghazali yet.
It seems what you really meant was:
> And third, they haven't read Al-Ghazali, don't quite understand how I make decisions.
Not everyone makes decision guided by the heart. Many people lean more on reason and logic.
> And third, they haven't read Al-Ghazali, don't quite understand how I make decisions.
Not everyone makes decision guided by the heart. Many people lean more on reason and logic.
> Many people lean more on reason and logic.
Yes, when theres's no impulse strong enough to outweigh reasoning. You don't need Ghazali for this, Kant also explains it. Before suggesting that I rephrase things, I think you should explore the domain first.
Yes, when theres's no impulse strong enough to outweigh reasoning. You don't need Ghazali for this, Kant also explains it. Before suggesting that I rephrase things, I think you should explore the domain first.
That’s beside the point. It’s perfectly valid to draw inspiration from Kant or Al-Ghazali for your decision-making framework, but neither explains how people actually make decisions in general-their work is fundamentally normative. By the way, I'd be surprised if a true Kantian would have arrived at the same decision as you.
akoculu(1)
> 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.
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.
The 3rd option is the one Azer describes in the post:
He wants to remove his stuff, but isn't sure what the right way to do it is, so he asks npm. npm provides him with a set of scripts to run to remove his stuff, and he, presuming that it's "ok" if npm told him to go ahead and run them, runs them. The impact isn't especially important to him, But since npm just gave him a set of scripts with an implicit "oh okay you want to remove your stuff, here I wrote you a script you can run to get it done," makes it more of an npm choice to handle it in this manner. npm asked him to handle it this way, so he did.
He wants to remove his stuff, but isn't sure what the right way to do it is, so he asks npm. npm provides him with a set of scripts to run to remove his stuff, and he, presuming that it's "ok" if npm told him to go ahead and run them, runs them. The impact isn't especially important to him, But since npm just gave him a set of scripts with an implicit "oh okay you want to remove your stuff, here I wrote you a script you can run to get it done," makes it more of an npm choice to handle it in this manner. npm asked him to handle it this way, so he did.
What would the alternative have looked like?
If NPM would have prevented the depublishing, he would have made a scene and in the worst case, they would have looked bad.
How they actually handled it, the library author got full freedom but also full responsibility
If NPM would have prevented the depublishing, he would have made a scene and in the worst case, they would have looked bad.
How they actually handled it, the library author got full freedom but also full responsibility
At a certain point, no, you can't unpublish because the world only has one arrow of time. Imagine if Torvalds decides to unpublish his code in the Linux kernel. It's easy to understand how that would work: His code would remain out there for all time because doing anything else would be a massive disruption and cause people actual problems. People don't just give others a way to hurt them like that if they know what they're doing, even if they got a lot of value from them in the past.
Lesson: Vendor your dependencies, I guess. Although a lot of the ire around left-pad was programmers using a library for something so trivial, but that's a different conversation.
Lesson: Vendor your dependencies, I guess. Although a lot of the ire around left-pad was programmers using a library for something so trivial, but that's a different conversation.
> Although a lot of the ire around left-pad was programmers using a library for something so trivial, but that's a different conversation.
Very true.
Although, from 2012 onwards, up to around the time of the leftpad incident, the trend - and the pressure - was to minimise the amount of work your code was doing and to publish tiny packages that only did one thing or solved one problem, deferring to other tiny packages for anything non-core. I remember colleagues more embedded in the JS world than I was passionately arguing for this in 2012/13.
And it did make some sense: bandwidth matters, particularly on mobile devices (which became a key source of traffic during that period) so why pull in some gigantic do everything library when you only need a handful of functions[0]? Sure, minifying and pruning help but, due to JS's nature, pruning can only get you so far.
But, yes, I think leftpad was something of a teaching moment on the downsides of this approach.
[0] Of course, if you then stick 6 different tracking scripts in all your pages, it's super-easy to undo all the good you've done by minimising your bundle size, but that's a different conversation.
Very true.
Although, from 2012 onwards, up to around the time of the leftpad incident, the trend - and the pressure - was to minimise the amount of work your code was doing and to publish tiny packages that only did one thing or solved one problem, deferring to other tiny packages for anything non-core. I remember colleagues more embedded in the JS world than I was passionately arguing for this in 2012/13.
And it did make some sense: bandwidth matters, particularly on mobile devices (which became a key source of traffic during that period) so why pull in some gigantic do everything library when you only need a handful of functions[0]? Sure, minifying and pruning help but, due to JS's nature, pruning can only get you so far.
But, yes, I think leftpad was something of a teaching moment on the downsides of this approach.
[0] Of course, if you then stick 6 different tracking scripts in all your pages, it's super-easy to undo all the good you've done by minimising your bundle size, but that's a different conversation.
> If NPM would have prevented the depublishing, he would have made a scene and in the worst case, they would have looked bad.
I mean he says he asked them to remove all his packages, expecting them to do so gradually, following whatever mitigation strategy they felt appropriate (e.g. some kind of warning and fadeout process), and instead they gave him a script to do it immediately so he did that.
I mean he says he asked them to remove all his packages, expecting them to do so gradually, following whatever mitigation strategy they felt appropriate (e.g. some kind of warning and fadeout process), and instead they gave him a script to do it immediately so he did that.
nindalf(2)
> and in the worst case, they would have looked bad.
As opposed to looking much worse? Easy decision.
As opposed to looking much worse? Easy decision.
Personally I understand both Al-Ghazali and "Not driven by logic, anger" parts very well. I have been in that position as well.
Being neutral and seeing a good way forward is not something practiced, taught or celebrated in western, esp. American culture much. One always needs to have a thrust source (mostly an emotion driven by logic, taught during being grown up (e.g.: You should be angry about it)) to make decisions.
In fact, sometimes, you just don't have a thrust source, you just feel like doing it. It feels the right thing to do, and you do it with no emotions attached.
This is a boon, in fact it's called "clarity" brought by being with yourself. Either spending time outdoors, doing some reflection work, or by meditating. I use the same methods when I face with a non-urgent but important decision. Let the way reveal itself. Putting logic and emotions aside and finding the right way is not easy, or the process is not smooth sailing, but I never arrived to a wrong place by following that path.
Being neutral and seeing a good way forward is not something practiced, taught or celebrated in western, esp. American culture much. One always needs to have a thrust source (mostly an emotion driven by logic, taught during being grown up (e.g.: You should be angry about it)) to make decisions.
In fact, sometimes, you just don't have a thrust source, you just feel like doing it. It feels the right thing to do, and you do it with no emotions attached.
This is a boon, in fact it's called "clarity" brought by being with yourself. Either spending time outdoors, doing some reflection work, or by meditating. I use the same methods when I face with a non-urgent but important decision. Let the way reveal itself. Putting logic and emotions aside and finding the right way is not easy, or the process is not smooth sailing, but I never arrived to a wrong place by following that path.
What’s anti-social is unilaterally making your code dependent on someone’s package and then getting mad at them when they choose to remove it.
This whole problem was trivially avoidable, and people get mad at him because they were too lazy to avoid it.
This whole problem was trivially avoidable, and people get mad at him because they were too lazy to avoid it.
They weren't too lazy to avoid it. Depending on other peoples' packages was actively encouraged within the JS community during that period, and the perceived benefits of doing so were loudly trumpeted.
And if you did without due diligence of the downsides, you have only yourself to blame.
Lots of people made a big mistake, they found out the hard way. Lesson learned.
Lots of people made a big mistake, they found out the hard way. Lesson learned.
Not to dump on the author, but following the Serenity Prayer would have led to a happier outcome...
grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference
grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference
He clearly could delete his packages so he did. In the left-pad incident, apparently, the community didn’t have the serenity to accept that.
Fair enough. If he considered that a victory, then good for him.
npn(1)
Who is al-Ghazali? I searched and found the Iraqi phisolopher, but couldn't understand how he is related
We westerns do the know much about the Socrates from the eastern side of the world. I can only imagine people from there know who al-Ghazali was just like we know who Sartre was.
So, im gonna try and read something by al-Ghazali.
So, im gonna try and read something by al-Ghazali.
Let me explain myself on this;
When this happened, people started making assumptions. A few of them:
1. I’m irrational 2. I’m angry 3. I’m greedy
They came to one of these conclusions, based on how they see themselves in the same position.
I can be of course one of these three in some other situations, but in the left pad incident, I done all purely with my heart, to stick to my values and principles which was behind my motivation to do open source for such a long time.
Ghazali is the best source I’m aware of about how to put heart in the driver seat of life, and without fighting but using logic, greed, anger etc as tools.
If my reference made curious about him, I couldn’t be more happy. Here’s a great lecture about his book, The Alchemy of Happiness: https://youtube.com/watch?v=zBwWc0DflRQ
When this happened, people started making assumptions. A few of them:
1. I’m irrational 2. I’m angry 3. I’m greedy
They came to one of these conclusions, based on how they see themselves in the same position.
I can be of course one of these three in some other situations, but in the left pad incident, I done all purely with my heart, to stick to my values and principles which was behind my motivation to do open source for such a long time.
Ghazali is the best source I’m aware of about how to put heart in the driver seat of life, and without fighting but using logic, greed, anger etc as tools.
If my reference made curious about him, I couldn’t be more happy. Here’s a great lecture about his book, The Alchemy of Happiness: https://youtube.com/watch?v=zBwWc0DflRQ
Hey - thank you for your interesting post today. It set me off on a personal journey which, in my mind, involved the discovery of many secret trails and camping spots, metaphorically ..
One thing I have learned about al-Ghazali today, thanks to your efforts, is that philosophers aren't always right, faith and logic can work together, and doubting everything can lead to truth.
But, most importantly, live ones faith honestly - and this is especially true for those of us who detest imperialist/corporate interference in spiritual activities, such as publishing packages to the npm ecosystem intended to make ones fellow human beings lives' more rewarding, in spite of the lack of personal rewards to be gained in doing so.. that the value in seeing this is lost on a lot of HN responses in this thread so far, is no big surprise - but it is surely disappointing.
I hope you will consider adding Aquinus and Augustine of Hippo to your references, also. Sometimes it helps to see how the universality of true philosophy crosses cultural divides.
One thing I have learned about al-Ghazali today, thanks to your efforts, is that philosophers aren't always right, faith and logic can work together, and doubting everything can lead to truth.
But, most importantly, live ones faith honestly - and this is especially true for those of us who detest imperialist/corporate interference in spiritual activities, such as publishing packages to the npm ecosystem intended to make ones fellow human beings lives' more rewarding, in spite of the lack of personal rewards to be gained in doing so.. that the value in seeing this is lost on a lot of HN responses in this thread so far, is no big surprise - but it is surely disappointing.
I hope you will consider adding Aquinus and Augustine of Hippo to your references, also. Sometimes it helps to see how the universality of true philosophy crosses cultural divides.
I bought the Alchemy of Happiness because of that sentence in your post. I always pay attention when someone recommends an author so earnestly.
so happy to hear this! I hope you enjoy the reading. Also, feel free to check out the 4 hours long audio lecture on the book. It's really good!
>(definitely the most pompous and self-important part of this post)
What compels you to say this? Would you be more satisfied if he'd suggested the reader acquaint themselves with Thomas Aquinas or Augustine of Hippo? Are you familiar with al-Ghazali, the scholar, or is he new to you?
You have, rather literally, proven the philosophers point - while remaining, it seems, ignorant of it.
Or perhaps, you mean to imply that /u/akoculu was doing a good deed not because he cared, but to show off?
The irony is, al-Ghazali asked his readers to question their pomp and self-importance, and to do good deeds because they truly cared, not because it would result in social acknowledgement by the mass collective, whose motives should always be questioned, effectively.
Perhaps, then, your position is more of a reflection of your own condition? One would hope your disdain is borne on an actual understanding of al-Ghazali's position, vis a vis self-doubt ... or rather, one would hope your current position is based on an ignorance of his works, actually.
One should never feel so compelled to deny the enlightenment of others, especially if by doing so, you resort to personally-motivated obscurantism in response.
What compels you to say this? Would you be more satisfied if he'd suggested the reader acquaint themselves with Thomas Aquinas or Augustine of Hippo? Are you familiar with al-Ghazali, the scholar, or is he new to you?
You have, rather literally, proven the philosophers point - while remaining, it seems, ignorant of it.
Or perhaps, you mean to imply that /u/akoculu was doing a good deed not because he cared, but to show off?
The irony is, al-Ghazali asked his readers to question their pomp and self-importance, and to do good deeds because they truly cared, not because it would result in social acknowledgement by the mass collective, whose motives should always be questioned, effectively.
Perhaps, then, your position is more of a reflection of your own condition? One would hope your disdain is borne on an actual understanding of al-Ghazali's position, vis a vis self-doubt ... or rather, one would hope your current position is based on an ignorance of his works, actually.
One should never feel so compelled to deny the enlightenment of others, especially if by doing so, you resort to personally-motivated obscurantism in response.
"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."
"Eschew flamebait. Avoid generic tangents."
"Edit out swipes."
https://news.ycombinator.com/newsguidelines.html
We detached this subthread from https://news.ycombinator.com/item?id=44245579.
"Eschew flamebait. Avoid generic tangents."
"Edit out swipes."
https://news.ycombinator.com/newsguidelines.html
We detached this subthread from https://news.ycombinator.com/item?id=44245579.
asdoi(1)
NPM (well Microsoft) forcibly took guy's package to give the name to this company: https://www.bbc.com/news/uk-45568276
Since then the name is basically squatted?
Whether you use left-pad or not is up to you... but this Kik story is just a bad look for Microsoft all around.
Since then the name is basically squatted?
Whether you use left-pad or not is up to you... but this Kik story is just a bad look for Microsoft all around.
You're aware this happened way before the Microsoft acquisition right?
> You're aware this happened way before the Microsoft acquisition right?
you phrasing implies that you would say what I said if you knew that acquisition happened later. Weird but OK.
Anyway then let's just say it is a bad look for NPM and any future buyers who decided this is a worthy company
you phrasing implies that you would say what I said if you knew that acquisition happened later. Weird but OK.
Anyway then let's just say it is a bad look for NPM and any future buyers who decided this is a worthy company
What is weird? Your phrasing implies that this happened under the stewardship of Microsoft (and is somehow related to Microsoft policies or leadership)
It was implied I wrote it knowingly. If that's what you would write knowingly sure, but I think it's weird.
Okay, I understand what you are saying now. You were not aware Microsoft did not own them yet. I did not glean that from your response
Yep, I would use different words if I was
That said, this seems like a weird argument to me:
> but I still don't understand why NPM didn't take the time to find out if any of my modules were widely used and consider ways to handle the unpublishing without breaking anything
Sure, NPM's unpublish mechanism was a misdesign, but is he saying that he expected people at the company to manually go through this every time someone did an unpublish? That doesn't seem too reasonable IMO, NPM the company isn't curating NPM the registry. They host it as a public service.
I can't fault the author all too much here though, if he hadn't triggered "the left-pad incident" then someone else would've not too long after. NPM fixed the problem, by means of a better unpublish policy [0] and that's that.
[0] https://docs.npmjs.com/policies/unpublish#packages-published...