| 1 |
On Fri, 13 Sep 2019 12:50:48 -0400 |
| 2 |
Michael Orlitzky <mjo@g.o> wrote: |
| 3 |
|
| 4 |
> The rule "don't copy and paste code" applies to your |
| 5 |
> linker just as much as it applies to the first program you wrote in |
| 6 |
> CS101, and for the same reasons. |
| 7 |
|
| 8 |
My experience has taught me to ignore the rule as written, and consider |
| 9 |
it more a guideline aimed at novices. |
| 10 |
|
| 11 |
Importantly, don't copy and paste code you don't understand. |
| 12 |
|
| 13 |
However, if you re-use a given implementation, you can sometimes become |
| 14 |
dependent on specifics in that implementation. |
| 15 |
|
| 16 |
And upstream have an annoying tendency to change implementation details |
| 17 |
in incompatible ways. |
| 18 |
|
| 19 |
This breaks your code, sometimes obviously, sometimes subtly. |
| 20 |
|
| 21 |
So the benefit you'd hoped to attain by modularity only remains true if |
| 22 |
the modules in question are immutable for the problem you're using them |
| 23 |
for. |
| 24 |
|
| 25 |
Also, these external modules bring with them complexity you may not |
| 26 |
want or need (and their own dependencies with the same issues), and |
| 27 |
that's not free either. |
| 28 |
|
| 29 |
Subsequently, when considering a new dependency, I have to ask |
| 30 |
questions about whether I can implement a subset of the dependency |
| 31 |
faithfully that suits my needs, and ask if I have the skills to be an |
| 32 |
expert in this implementation. |
| 33 |
|
| 34 |
A level of distrust in the people who author and maintain your |
| 35 |
dependencies is something I consider healthy. |
| 36 |
|
| 37 |
Does this map at all to static linking? You bet. |
| 38 |
|
| 39 |
And that's part of why Go and Rust use it. The fragility of |
| 40 |
other-peoples code in the long view of time is high, because with |
| 41 |
dynamic linking, you don't have any guarantees about integrity. |
| 42 |
|
| 43 |
You have to cross your fingers and hope upstream so-named their |
| 44 |
libraries right, hope upstream changed their API markers right, hope |
| 45 |
upstream never accidentally made a breaking change without changing an |
| 46 |
API marker, hope your code doesn't need a mountain of work to recompile |
| 47 |
after the API marker changes, and hope upstream/gentoo maintainers for |
| 48 |
your package can still be bothered to ship fixes for the API consumer. |
| 49 |
|
| 50 |
That last paragraph sums up a large volume of the daily hell of being a |
| 51 |
maintainer and a gentoo user. |
| 52 |
|
| 53 |
Static linking is more a result of a sickness, not the sickness itself. |
Archives