External Dependencies and why the mold must be broken

It’s not hard to see the appeal of dynamic linking. Just look at all the things in common between programs, they all have printf and fopen. Wouldn’t it be efficient if we could collect together all the common program texts in a file and in memory? Yes, that would be more efficient. But there is a hidden cost, a negative externality. The gains of dynamic linking are only had when using the system libraries. Therefore one must depend on their existance and proper function. You might say that the ability to perform security patches and bug fixes on shared libraries is useful. But you don’t know what programs will break due to your changes. Hell, you might not even have the programs installed. Imagine you want to run an old game from 10 years ago. Only to find out that the shared libraries it depends upon either don’t exist or work properly. But you are lucky and find a 10 year old version of the dynamic library. Except it in turn needs other non existant dynamic libraries to work. Perhaps you are blessed by god and manage to get all the dependencies. Now you have to juggle several versions of a library on your machine, and keep track of which application needs what. This is not a sustainable solution.

Software is a 50 year old discipline, soon it will be 100. It should be obvious that we ought be doing our best to write software for permanence. Therefore I would like to suggest that we attempt to minimize the external dependencies of our programs. In all manners, even though that might be aspirational, since it is through aspiration we gain direction. In no particular order, we should avoid depending on:

The Operating System as a mold

The OS is the foundation on which we run all our software. Thus, it is apparent that our software is shaped by said foundation. Especially since all external dependencies are facilitated by it. Currently it seems our OS’s have an all or nothing approach. Either you can dynamically link or not. You can access the internet or not. You can run external programs or not. You can read the filesystem or not. These limitations are additionally often global, or atleast very coarse. We are hesitant to limit external dependencies for we desperatly need them sometimes. If we designed an OS with explicit and user approved external dependency use, we could provide friction and incentivize good application design.

Now, if you like me believe this flavour of OS is something we should strive for, there lie roadblocks ahead of us. By deviating from the norm, we maroon ourselves from a usability standpoint. There are currently no programs written with this style of OS in mind. And no sane app developer would target our platform since we only add constraints and have no marketshare to offer in return. Luckily though, nothing in history started mainstream.

If we can unite those crazy enough for this idea, we can start to build. And as we build, those who are slightly less crazy will see sufficient potential to get onboard. As the snowball rolls, it get’s larger. And it’s growth can go exponential, given that the people and product provide real value. The world was made by people no greater than you or me. I’d say it’s a perfect time to change it for the better

“External Dependencies and why the mold must be broken” was written by Sam H Smith on the 23rd of September 2021, 2021-09-23.

Back to the blog