If the dependency solves a thing you need and isn't part of your core business, it pretty much is 100% positive. E.g, do you really want to implement your own json parser? When will you then ship your actual product?
I'm answering to the claim that "dependency as a concept itself is good". They're not universally good, and have side effects even when they solve the problem at hand.
The answer to your questions is already in my reply.
>do you really want to implement your own json parser?
On the recreational and creative side, maybe, but not as much as coming with an original exchange format which is a better feat to the specific case at hand.
On a professional side, if JSON support is a burden engraved in the specification so be it. Then having the transformation of the PL native data structure back and forth to various other formats shipped in the standard library is really the best that can hoped. As second best case it is having a single clearly preponderant and well maintained library. Otherwise, bet among a plethora of possible libraries is becoming less attractive compared to building something internally brewed.
The part you are missing: If something in the dependency isn't working as you'd like at some point later, making your code work as you desire may be dramatically more difficult than if you hadn't brought it in.
Sure, nothing is, but where you draw the line? And why would you implement something again when you are unlikely to do it better, or even have time for it?
And of course, if you're doing just recreational coding to learn something, or if what you need differs from what is available, or the available thing seems sketchy somehow, then you'd write it yourself (if it's feasible). But for most things where what you need is clear and unambiguous, I don't see why you'd invent it yourself. For an established library it's unlikely that you'd do any better anyway.
(And again, if it's recreational what you are doing, you want to learn and have a hobby, of course, do it yourself. But in that case, you aren't actually looking for dependencies anyway - your goal is elsewhere.)
One should draw a different line depending on the situation. That's where the engineering comes in. There is no silver bullet. We should still be suspicious and judicious about every single dependency.
> So with infinite resources it would be best to write everything from scratch?
Re-read the parent and the other replies: A critical point you are missing is your interlocutor's practical mindset in contrast to your idealistic one. This is about making engineering-mindset tradeoffs; they vary depending on the specific scenario. The answer to your Reductio ad absurdum is yes, but I believe that side tracks rather than elucidates.
The explicit re-statement: There is no general line to draw of whether to use a dependency, or write code internally using a language's primitives (Or already-used libs); it varies based on the situation, and there is a high degree of subjectivity in each of these choices.
- How much work would it take to implement and maintain this if done without a library?
- What other libraries are available?
- Does this library meet our needs superficially, or will it be a robust solution long-term?
- When our requirements change slightly, or we need to add or change features, will this library still work?
- How much code architecture needs to change to integrate this? Does it require changing other parts of the program that it seems should not be required to change for the reason we are bringing this in?
- What impact does including this have on binary size and compile time?
- What is the risk of security vulnerabilities?
- Does this library have its own deep dependency tree?
- Will this require continuous maintenance to keep it in sync with other dependencies?
- Does this library require certain system dependencies to be installed that will make the build more fragile / less portable?
- Will using this dependency impact performance over implementing manually? (Or over another dependency)
A good dependency solves a well defined problem with a direct API towards it, so yes, if the dependencies you talk about aren't high quality then yes, don't use those.
