Post #4039766
2026-07-23 12:12 UTC
Basically, it's only at the very final linking phase where we actually have maximum context for what functionality is actually required, what shapes of data are needed, etc. Really, it's at *invocation* time, but executables are usually a pretty nice boundary line for "here's a suite of things that are possible if you ask for them, as a complete and cohesive product." The goal is itself multifaceted here.
The further back we get from final linking, the less specificity we have about what's needed vs could be needed. This is part of the ratchet pattern that bloats software over time. I'm not anti-library. This is what makes being a library author such hard work, if you actually care about the quality of what you make! A lot of the things I associate with software best practices (on my own terms of "best") basically require a specificity that is structurally denied to library authors. So... what do?
Replies (1)
-
@MaddieM4@raphus.social 2026-07-23 12:18
The best answer I have at a big scale is to break software into small pieces that are allowed permanence/completion, and relieved of the responsibility to be the right tool for every job. https://maddiem4.cc/blog/fuller-stack/002a-immutability-as-maintenance-doctrine In practice, this means relying on things like generic types, interfaces, or even duck types to allow library code to be small, purposeful, humble, and flexible. This allows you to push as many decisions as possible as late as possible, so that composition freedom is moved to the final application developer's plate to the highest achievable degree.