Chris's Wiki :: blog/programming/DependenciesEnablePrograms Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/DependenciesEnablePrograms?atomcommentsDWiki2020-02-07T10:49:57ZRecent comments in Chris's Wiki :: blog/programming/DependenciesEnablePrograms.By dozzie on /blog/programming/DependenciesEnableProgramstag:CSpace:blog/programming/DependenciesEnablePrograms:d7a7ba5e0932fa0d9e2dbb72f6766743ae3a03a2dozzie<div class="wikitext"><p>Because dependencies are not <em>inherently insane</em>, they merely <em>have
a long-term cost</em>. 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</div>2020-02-07T10:49:57Z