Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never use a dependency that you could replace with an afternoon of programming

blog.carlmjohnson.net

Post reply on HN
Print view View original

11–20 of 333 posts

Re: Never use a dependency that you could replace with an afternoon of programming

#11

Post by lgessler »

mcqueenjordan wrote: post #5

Avoiding dependencies is a noble goal, and something to be valued, but this simple rule is too simplistic. The problem lies in the fact that there are a great many things I can hack together in an afternoon to "replace" some kind of external dependency, but the quality discrepancy of these hacks is highly variant. My understanding of what can or should be done in an afternoon might differ with my colleagues'. Unfortu…

Agreed. For libs that are "afternoon-y" in their scope (so, not an HTTP server or crypto), if you need to get off the fence you can use some cheap heuristics to assess the quality of a library without auditing its code. For instance, you can look at its popularity (in downloads or Github stars), its release/version history, its number of open issues, and its development activity. If I see high issue counts and many major releases with breaking changes, I'm going to avoid it. If I see 2+ years of stability with mostly minor releases, low issue counts, and high use rates, I figure it's going to probably be better than whatever half-baked solution I could scribble in an afternoon.

Re: Never use a dependency that you could replace with an afternoon of programming

#12

Post by closeparen »

The single best way to avoid dependencies is to use a language with a large standard library.

Given the variance in standard library coverage, it’s rarely productive to argue about this topic in a language agnostic way. Using only stdlib in Go is very different from using only stdlib in JavaScript.

Re: Never use a dependency that you could replace with an afternoon of programming

#15

Post by brightball »

tmaly wrote: post #10

This reminds me of the Node left-pad module problem in a way. I think if something is so trivial to write, you should write it rather than using a dependency. If it is non-trivial, I prefer the official standard libraries for a programming language. That is if a solution exists in the standard library. I think the Go standard library with its batteries included mantra and the level of support it gets is good example…

Or just C&P the relevant open source code (license allowing).

Removing a dependency doesn’t have to mean writing from scratch.

Re: Never use a dependency that you could replace with an afternoon of programming

#16

Post by alkonaut »

jasonpeacock wrote: post #6

This is horrible advice. There's a reason that you don't write your own hashtable implementations. Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version. All that work of finding existing solutions and learning how to use them? That's part of the job. Find a bug in the dependency? Su…

> I can write a hashtable implementation in an afternoon, but it's going to have bugs

If it has any bugs that would surface in a year of production (while the dependency version wouldn't) then you didn't write an equivalent in an afternoon.

The advice, if it's to be useful at all, must be things that you could completely replace in the same quality, in an afternoon.

It's the left-pads and is-odds, to begin with.

Re: Never use a dependency that you could replace with an afternoon of programming

#17

Post by asplake »

jasonpeacock wrote: post #6

This is horrible advice. There's a reason that you don't write your own hashtable implementations. Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version. All that work of finding existing solutions and learning how to use them? That's part of the job. Find a bug in the dependency? Su…

Never use a dependency if you could write something of equivalent quality in afternoon. Seems reasonable enough.

Re: Never use a dependency that you could replace with an afternoon of programming

#18

Post by tluyben2 »

sparker72678 wrote: post #14

Probably good advice, but when was the last time a programmer accurately scoped a problem when they said it will take “an afternoon” to build?

That is the issue I have with it: ‘an afternoon’ is already way too vague. Make it ‘5 minutes’ (left pad etc) then I think it works out.

Re: Never use a dependency that you could replace with an afternoon of programming

#19

Post by mcphage »

(1) Most programs don't have that many direct dependencies, especially smaller dependencies. It's often dependencies of dependencies. In npm, adding just `jest` will make your `node_modules` directory explode.

(2) if Linus's Law is "given enough eyeballs, all bugs are shallow", then having fewer eyes on a library means more bugs.

(3) Oftentimes you think you can replace a dependency with an afternoon of programming, but it turns out, it's not quite as simple as you think.

(4) Sometimes you only use a small piece of a library to start with, but over time use more and more. If it's your own code, then you're going to be continuously refactoring, updating, rewriting it. If it's a library, then you can just start using the additional pieces as you need.

Post reply on HN