Comment by lmm
11 years ago
> Regardless I don't think I'd ever call very elementary code a "maintenance burden". Ever.
Every line is another line that maintainers have to read and understand.
> The point being: where it's possible to mitigate and remove dependencies I think you'd be crazy not to. Every dependency you can lose is another potential build issue or attack surface you're removing from your project.
Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them - but resolving them is an O(1) problem no matter how many dependencies you have. Just like if you've already written a good general-purpose sorting function, there's no point writing a separate integer sort routine, even if the implementation could be simpler than the general-purpose one. You already depend on your packaging/dependency tools, so you might as well use them all the time.
> Every line is another line that maintainers have to read and understand.
Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity.
> Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them
Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).
> Just like if you've already written a good general-purpose sorting function, there's no point writing a separate integer sort routine, even if the implementation could be simpler than the general-purpose one.
Not sure what you're getting at. If you need a sorting function you can probably use whatever is built into the language unless you need to sort across a distributed data set in which case write something or find a dependency to use.
> You already depend on your packaging/dependency tools, so you might as well use them all the time.
Absolutely, unequivocally, no. What you're saying is you should install and use dependencies, from third parties which you do not know anything about, for every single, possible thing just so you can use the tools "all the time". That's so irresponsible and backwards.
Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you? Then grab it by all means. But don't use it for every tiny function and for loop just because you want someone else to maintain it.
> Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity.
Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.
> Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).
So figure out a process and resolve that, once and for all. There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.
> Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you?
That's exactly why people were depending on this library.
> Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.
I'm sorry but that is just a horrible way to look at programming.
You shouldn't NEED to go out and look for an already done solution if it's elementary and takes minutes, if that, to write. Ever.
This is just sloppy.
> So figure out a process and resolve that, once and for all.
Tell yourself that; that was simply a counter argument to your false claim. Regardless it's fixable.
> There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.
This doesn't even make sense. What are you trying to convey here? The more dependencies you can cut out the more reproducible your builds will be. Period. Which is important when you're dealing with code that gets rapidly deployed to many production boxes.
> That's exactly why people were depending on this library.
If using left pad gave them time back because the original author could do it better, faster and cheaper...I'm not sure programming is the right type of work for these people.
What's next, are you going to outsource all your for and while loops to a module? You know, so you have less things to "maintain"?
1 reply →