Hacker News Reader

Comment by esailija | Hacker News Reader

The possibility of having bugs in code you don't control (that usually has a clause for no warranties) is an argument for implementing it yourself, not against it. Don't forget how hard it is to get a maintainer even agree on whether something is 1. a bug 2. that needs to be fixed.

View on HN

The reality, however, is that if you took this point of view, you will spend your time reinventing the wheel, introducing bugs and wasting resources. That's how it works in real life.

If someone already wrote the base code, we can always fork it and fix a bug or add a feature ourselves if it runs contrary to what the original authors desires.

Even getting a response just so you can know what the original author desires can take a long time and there is no warranties or guarantees that you will even get any response. To me, all the downsides that come with dependencies are not even close to worth it for saving 15 seconds.

Who cares what the original author desires?

If you fixed the bad behavior you're experiencing, and the original author's effort saved you hours or days of coding, what's the downside?

Perhaps I'm not arguing for 15 second long code changes. But other than typing a single if statement, what takes literally less than one minute to securely change in any partially-complex project?

Fair point. One does run the risk of having bugs in code out of their control by using a package manager such as NPM, but one gains a swath of other programmers inspecting the modules for bugs. And in module repositories for interpreted languages, its very much in your control to fix any bugs you might find, regardless of what the maintainer might say about it.

Reply on news.ycombinator.com