5 ms·

>Also, you should look at least at the docs of the packages you install Brb reading the docs for every micro-package installed as a dependency for what I just

by mdszy 7y ago

>Also, you should look at least at the docs of the packages you install Brb reading the docs for every micro-package installed as a dependency for what I just installed that provides functionality that could've been hand written in five minutes. Gonna spend the next few months reading about a thousand package README's for this single package I installed and all its dependencies down the tree, be right back.

falcolas 7y ago
You say that like it's not a good thing to do? If you pull a library into your project, you're taking responsibility for that library, for better and worse.
- mdszy 7y ago
  I'm talking about how that's completely not feasible anymore because of how every project has dependencies upon dependencies upon dependencies because the general development attitude has shifted towards "import a single library that tells you if a number is odd, and another library to tell you if one is even"
  - mperdoni 7y ago
    Ultimately, if a bug in a library causes issue with your program, and your company loses $X, your superiors will not give a shit. You have the burden of responsibility for the program. For common major libraries used worldwide in enterprise products, you are right in that there is an element of trust. They are made by people much faster/better/stronger than most of us. If all else fails, the sheer magnitude of people using it is a small insurance policy, as disastrous issues will probably be quickly apparent. That still doesn't absolve you of responsibility, but the overall risk is usually pretty low. A segment of code on SO, or a weeny niche library? You only have your noggin to vouch for its stability and accuracy.
    - mdszy 7y ago
      >They are made by people much faster/better/stronger than most of us. lmfao no they're not
    - jodrellblank 7y ago
      > You have the burden of responsibility for the program. What does that mean when the developer who committed it might have left long ago? I'm assuming you mean more than "blame" which is a pretty unhelpful response for a company to have, but then what exactly is "burden of responsibility" which should have this bus-factor-of-1 attitude around it, and why?
theamk 7y ago
No, the way it works you read the docs for the packages you directly use (import from code), and you hope that package authors did the same for their dependencies. (this encourages one to keep number of at least dependencies small, which is pretty good idea in general)
drngdds 7y ago
You're just making an argument against the NPM model of installing five billion packages

by mdszy 7y ago

falcolas 7y ago

You say that like it's not a good thing to do? If you pull a library into your project, you're taking responsibility for that library, for better and worse.

mdszy 7y ago
I'm talking about how that's completely not feasible anymore because of how every project has dependencies upon dependencies upon dependencies because the general development attitude has shifted towards "import a single library that tells you if a number is odd, and another library to tell you if one is even"
- mperdoni 7y ago
  Ultimately, if a bug in a library causes issue with your program, and your company loses $X, your superiors will not give a shit. You have the burden of responsibility for the program. For common major libraries used worldwide in enterprise products, you are right in that there is an element of trust. They are made by people much faster/better/stronger than most of us. If all else fails, the sheer magnitude of people using it is a small insurance policy, as disastrous issues will probably be quickly apparent. That still doesn't absolve you of responsibility, but the overall risk is usually pretty low. A segment of code on SO, or a weeny niche library? You only have your noggin to vouch for its stability and accuracy.
  - mdszy 7y ago
    >They are made by people much faster/better/stronger than most of us. lmfao no they're not
  - jodrellblank 7y ago
    > You have the burden of responsibility for the program. What does that mean when the developer who committed it might have left long ago? I'm assuming you mean more than "blame" which is a pretty unhelpful response for a company to have, but then what exactly is "burden of responsibility" which should have this bus-factor-of-1 attitude around it, and why?

theamk 7y ago

No, the way it works you read the docs for the packages you directly use (import from code), and you hope that package authors did the same for their dependencies. (this encourages one to keep number of at least dependencies small, which is pretty good idea in general)

drngdds 7y ago

You're just making an argument against the NPM model of installing five billion packages