3 ms·

I hate to spoil the fun for everyone. But there is actual value in doing things the npm/unix way. Just yesterday I used a module to turn numbers to comma sepa

I hate to spoil the fun for everyone. But there is actual value in doing things the npm/unix way. Just yesterday I used a module to turn numbers to comma separated strings 10000 -> 10,000 Could I have written a function to do it ? Sure But every less line of code I need to write saves me time. Programming is fundamentally a creative field ( which means there is no absolute truths ) - and each individual developer should be given the freedom judge when to write code and when to use other's people modules. I would say that this whole fiasco just proves how awesome programming has become - remember the days when adding a dependency was hell ? Now we live in a world where adding dependency has so little cost that we rather not even spend 10 minutes writing a function. To me its an improvement over the state of affairs from the past. Its also cheaper to switch dependencies - imagine if the leftpad disaster was somewhere in the window's kernel ? or in std:: ? There is always trade-offs in every decision you make in software - I think we are moving in the right direction. Just need to make package creation immutable.

DannyBee 11y ago
"But there is actual value in doing things the npm/unix way." This is where the node community falls down. They think because there is value in sometimes doing it this way, there is always value in doing it this way. Rarely is the right answer for architecture/programming/etc at one of the extremes.
- hugozap 11y ago
  Composing from small modules has worked great so far. Yeah, npm had a flaw, but people are mixing modularity with a package distribution issue.
  - DannyBee 11y ago
    What about the last 16 javascript software engineering fads? What happened to those?
- pcwalton 11y ago
  The left-pad debacle is not an indictment of small dependencies. The problem would have still happened even if left-pad were a 10,000-line dependency, if that 10,000-line left-pad was as popular as the 10-line left-pad was. The issue was that authors in the npm ecosystem could pull their packages and cause havoc. Copying code is a partial workaround for this problem for small dependencies only, but the problem should be solved at the npm level--and once it's solved there, the virtues of copying code go away.
  - DannyBee 11y ago
    I don't buy your argument that "the virtues of copying code go away" in any way, shape or form. It seems somewhat arrogant to me to think that people have spend decades on software engineering approaches to these kinds of issues, but y'all think "yeah, we solved that, no problem!". But I'm not going to argue this further. I guess time will tell.
    - pcwalton 11y ago
      This doesn't seem responsive to my argument at all. I'm speaking from experience with a package manager that was specifically designed up front to avoid the left-pad issue (before left-pad even was a thing). In that environment, dependencies, even small ones, are great. With an overrides feature and lockfiles, you get all the benefit of copying code (ability to hack on it, responsibility for updates, reproducible builds) without the hassles of copying code and trying to stay in sync with upstream. Copying code isn't something you have to spend decades to invent. Rather, I see it as giving up on proper package management. There are coherent arguments that package managers aren't worth it (though I disagree with them), but I don't agree that it's arrogant to try to build package managers that scale up and down, any more than any attempt to use software to solve an engineering problem is arrogant.
andreasklinger 11y ago
Additionally: The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. Which is - no matter how big the packages are - a huge problem.
- msbarnett 11y ago
  > Additionally: The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. Which is - no matter how big the packages are - a huge problem. This really misses the point. Every dependency is its own point of failure. When you explode your dependency tree into 1,000s of individual dependencies, you vastly increase the odds of something going wrong. Making package publishing immutable won't save you. What happens when the dev of one of those 1,000 packages you rely on has his or her account hacked and a malicious point revision is pushed? Even if you pin all your dependencies, do all your 1,000 dependencies pin all of theirs? Micropackages like left_pad and is_array had hundreds of dependent packages and a tiny handful of watchers on the repo itself. The NPM community is lucky that the first major consequence of their micropackage-insanity was only a brief outage.
- jldugger 11y ago
  > The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. I figure the social dynamics bundled with a micropackage model matter. If you have a few big packages with lots of owners, central dependencies are less likely to be deleted by unanimous consent of owners than the same software divided up into many packages each with a single owner.
chc 11y ago
I think the reason people felt it was silly is that there is a whole library (a tiny one, sure, but still a dedicated library) for that one function. If there had been a left-pad function in a larger utility library that everyone was using, nobody would have thought it was silly.
- hugozap 11y ago
  Why would a larger utility library would have been better? Replacing a big dependency is much more difficult. If the reason is "because now a lot of dependencies could dissappear/change" then that's an argument against the npm inmutable history issue and not modularity.
userbinator 11y ago
But every less line of code I need to write saves me time. How much time did you take to find the code, read the documentation for it to make sure it does exactly what you need, did you budget time for the future when it doesn't work exactly as you wanted and you'll have to either find another module or fix it yourself, etc.? If it's something nontrivial (e.g. SSL/TLS), then it certainly makes sense to reuse. But if it's trivial, then the overhead can be far greater than the savings. Of course, the definition of "trivial" varies greatly depending on the skill level of the programmer.
bitwize 11y ago
left-pad not a BUILT IN language primitive --- NON-STARTER! Dammit people! http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/0545...
pdkl95 11y ago
> But there is actual value OF course there's value. There is also a cost to adding another dependency. > But every less line of code I need to write saves me time. It saves you time now. The recent left-pad brouhaha is a very good example of how it can also waste a lot more time. This focus on only the initial development time without any consideration of the maintenance cost always creates problems in the long-term. Maybe this attitude is popular with programmers on short contracts that won't be around to maintain the project? It sounds plausible, but I'm not sure. At a minimum this shows the human tendency to be very bad at evaluating risk.
anexprogrammer 11y ago
npm != unix, don't conflate the two. The bar for publishing needs to be higher because there is too much broken, incomplete shite out there. Usually because they just pushed the internal quality, undocumented, untested garbage they just wrote. Don't test arguments, don't set constraints. Tag on a sentence of hurried description, done. I don't understand the half-assed mentality that does that. That's how one makes the world a worse place, not a better one.

DannyBee 11y ago

"But there is actual value in doing things the npm/unix way." This is where the node community falls down. They think because there is value in sometimes doing it this way, there is always value in doing it this way. Rarely is the right answer for architecture/programming/etc at one of the extremes.

hugozap 11y ago
Composing from small modules has worked great so far. Yeah, npm had a flaw, but people are mixing modularity with a package distribution issue.
- DannyBee 11y ago
  What about the last 16 javascript software engineering fads? What happened to those?
pcwalton 11y ago
The left-pad debacle is not an indictment of small dependencies. The problem would have still happened even if left-pad were a 10,000-line dependency, if that 10,000-line left-pad was as popular as the 10-line left-pad was. The issue was that authors in the npm ecosystem could pull their packages and cause havoc. Copying code is a partial workaround for this problem for small dependencies only, but the problem should be solved at the npm level--and once it's solved there, the virtues of copying code go away.
- DannyBee 11y ago
  I don't buy your argument that "the virtues of copying code go away" in any way, shape or form. It seems somewhat arrogant to me to think that people have spend decades on software engineering approaches to these kinds of issues, but y'all think "yeah, we solved that, no problem!". But I'm not going to argue this further. I guess time will tell.
  - pcwalton 11y ago
    This doesn't seem responsive to my argument at all. I'm speaking from experience with a package manager that was specifically designed up front to avoid the left-pad issue (before left-pad even was a thing). In that environment, dependencies, even small ones, are great. With an overrides feature and lockfiles, you get all the benefit of copying code (ability to hack on it, responsibility for updates, reproducible builds) without the hassles of copying code and trying to stay in sync with upstream. Copying code isn't something you have to spend decades to invent. Rather, I see it as giving up on proper package management. There are coherent arguments that package managers aren't worth it (though I disagree with them), but I don't agree that it's arrogant to try to build package managers that scale up and down, any more than any attempt to use software to solve an engineering problem is arrogant.

andreasklinger 11y ago

Additionally: The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. Which is - no matter how big the packages are - a huge problem.

msbarnett 11y ago
> Additionally: The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. Which is - no matter how big the packages are - a huge problem. This really misses the point. Every dependency is its own point of failure. When you explode your dependency tree into 1,000s of individual dependencies, you vastly increase the odds of something going wrong. Making package publishing immutable won't save you. What happens when the dev of one of those 1,000 packages you rely on has his or her account hacked and a malicious point revision is pushed? Even if you pin all your dependencies, do all your 1,000 dependencies pin all of theirs? Micropackages like left_pad and is_array had hundreds of dependent packages and a tiny handful of watchers on the repo itself. The NPM community is lucky that the first major consequence of their micropackage-insanity was only a brief outage.
jldugger 11y ago
> The core problem wasn't the existence or the reliance of dependencies. But simply the fact that the package was no longer available. I figure the social dynamics bundled with a micropackage model matter. If you have a few big packages with lots of owners, central dependencies are less likely to be deleted by unanimous consent of owners than the same software divided up into many packages each with a single owner.

chc 11y ago

I think the reason people felt it was silly is that there is a whole library (a tiny one, sure, but still a dedicated library) for that one function. If there had been a left-pad function in a larger utility library that everyone was using, nobody would have thought it was silly.

hugozap 11y ago
Why would a larger utility library would have been better? Replacing a big dependency is much more difficult. If the reason is "because now a lot of dependencies could dissappear/change" then that's an argument against the npm inmutable history issue and not modularity.

userbinator 11y ago

But every less line of code I need to write saves me time. How much time did you take to find the code, read the documentation for it to make sure it does exactly what you need, did you budget time for the future when it doesn't work exactly as you wanted and you'll have to either find another module or fix it yourself, etc.? If it's something nontrivial (e.g. SSL/TLS), then it certainly makes sense to reuse. But if it's trivial, then the overhead can be far greater than the savings. Of course, the definition of "trivial" varies greatly depending on the skill level of the programmer.

bitwize 11y ago

left-pad not a BUILT IN language primitive --- NON-STARTER! Dammit people! http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/0545...

pdkl95 11y ago

> But there is actual value OF course there's value. There is also a cost to adding another dependency. > But every less line of code I need to write saves me time. It saves you time now. The recent left-pad brouhaha is a very good example of how it can also waste a lot more time. This focus on only the initial development time without any consideration of the maintenance cost always creates problems in the long-term. Maybe this attitude is popular with programmers on short contracts that won't be around to maintain the project? It sounds plausible, but I'm not sure. At a minimum this shows the human tendency to be very bad at evaluating risk.

anexprogrammer 11y ago

npm != unix, don't conflate the two. The bar for publishing needs to be higher because there is too much broken, incomplete shite out there. Usually because they just pushed the internal quality, undocumented, untested garbage they just wrote. Don't test arguments, don't set constraints. Tag on a sentence of hurried description, done. I don't understand the half-assed mentality that does that. That's how one makes the world a worse place, not a better one.