I frequently use dependencies because they enable my programs to exist

February 7, 2020

I was recently reading Drew DeVault's Dependencies and maintainers, which I encourage you to read too (it's short). To me, the climax of DeVault's post is the following:

[...] The idea of depending on a library I’ve never heard of, several degrees removed via transitive dependencies, maintained by someone I’ve never met and have no intention of speaking to, is absolutely nuts to me. [...]

I can't speak for anyone but myself, but as it happens I have at least two Go programs that use significant external dependencies; my program for lightweight remote control of Unix Firefox on X and my SNTP query program. I've never looked deeply into the state of the dependencies for either, and certainly I haven't checked for transitive dependencies.

Why not is pretty straightforward. Both of these programs exist because relying on their dependencies made them simple and fast to write. Had they been larger projects, neither of them would even have been written; it would not be worth the time and the bother (especially for my SNTP query program). If you're writing programs with limited time, you pretty much have to take dependencies on trust. Not only do you not have the time to conduct a significant investigation or become really involved in the community, you also don't have any real alternative because you can't afford to recreate the dependency yourself. Either the dependency works out or you don't have a program, so you might as well assume it will work out and try.

(This would be a bad idea if you were going to invest significant amounts of work into writing your program, but this is for small, readily written programs where you're not out much time if you code something and it fails.)

PS: Sometimes I use dependencies because they make my life easier and get things done faster, even if I could theoretically live without them. This is the case for using a dependency for option handling in my Go programs; it's not strictly necessary, but it works and it's more pleasant than Go's standard flag package.

Comments on this page:

By dozzie at 2020-02-07 05:49:57:

Because dependencies are not inherently insane, they merely have a long-term cost. This cost shows up in various places, e.g. your code breaks on upgrade or just on rebuild (when you pull dependencies from the internets), or you need to put in more effort to make a proper package out of it, or recompilation of all the things on OS upgrade is more expensive and laborous, or something like that.

The problem is not using dependencies at all, the problem is using them without any regard to the cost, by saying that it's trivial to add an external library. A dependency has to bring you enough to justify the long-term cost of adding it, that's all.

Long time ago, adding a dependency to a program was troublesome, so programmers only used external libraries when it really helped. Nowadays, adding a dependency is very easy on the spot, so we have left-pad thing and a simple search web form that can display results in a table and a plot (Kibana) that weighs whole 200MB, seven times as much as the full, feature-rich database engine of PostgreSQL.

The friction of adding a dependency may have been embedded in the wrong place back then, but it was an appropriate amount. Now the friction is lower, which is not a good thing overall, because now there's nothing that would tell the programmers that dependencies have a cost, except for the programmers' experience, and programmers by large are not experienced enough.

Written on 07 February 2020.
« The drawback of having a dynamic site with a lot of URLs on today's web
Ways that I have lost the source code for installed programs »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Feb 7 01:27:30 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.