IMO the biggest factor in optimization in modern software is libraries.
Modern software often results in larger size files due, in part, to the utilization of numerous libraries and frameworks, which have become an integral part of software development. Libraries provide pre-written code, functions, and modules that developers can leverage to enhance functionality, save time, and ensure more stable and reliable code. However, the trade-off is that these libraries can be quite extensive, containing many additional features and resources that a particular software may not utilize in its entirety. This "bloat" accumulates when developers incorporate several libraries, each possibly containing superfluous code and data, thereby inflating the overall size of the software. Moreover, to prioritize rapid development, ease of use, and robustness, modern software tends to bundle together diverse functionalities and features through these libraries, even if only a subset is required for a particular application, contributing further to the expansion of file sizes and resource demands. This phenomenon can be observed across various software applications, from desktop programs to mobile apps, where developers prioritize feature-rich, multifaceted, and user-friendly environments, which often necessitate the integration of comprehensive libraries and framework.
So, if it is really important for a specific user case (perhaps application needs to fit into a very small size), work can be done to reduce reliance on libraries, and ensure only the bare minimum of code is required, however this requires more time investment.
If so many of today's programs rely on libraries, why not share them among programs? I.e. you'd install all the libraries upfront on a new computer so that programs need not ship with their own copies?
While the idea of sharing libraries among programs to reduce individual software size is sound in principle and does get implemented in certain contexts (e.g., shared DLLs in Windows, shared libraries in Unix/Linux), numerous challenges and issues arise with a universal application of this concept.
Version Conflict: Different applications might require different versions of a library due to dependency on particular features or configurations. Having a single shared version could introduce compatibility issues.
Security and Stability: If a shared library gets updated, it might introduce bugs or alter functionality in a way that affects all software relying on it. This can introduce unexpected behavior or vulnerabilities into applications that were stable with a prior version of the library.
Customization: Developers often use customized versions of libraries, which might be modified to suit the specific needs of their application. Sharing such customized libraries centrally could create conflicts and complicate software development and deployment.
Dependency Management: Managing shared libraries, ensuring all are up-to-date and compatible with all installed software, would require a robust and complex dependency management system, which could be challenging to create and maintain.
User Experience: For end-users, a need to manage, update, and troubleshoot issues with shared libraries may prove to be a complex and frustrating experience, especially for those not versed in technical troubleshooting.
Isolation and Sandboxing: Modern software design often prioritizes isolating applications to enhance security and stability. This means ensuring that the failure or compromise of one component (e.g., a library) does not impact others. Sharing libraries could undermine this isolation.
Despite these challenges, some operating systems and development environments do utilize shared libraries to a certain extent, managing some of these challenges to leverage the benefits of reduced redundancy and resource usage. However, striking the right balance between shared and bundled resources continues to be a complex and nuanced aspect of software design and deployment.
Damn. Thanks for the explanation. Sounds like modern software and development thereof is hell!
(post is archived)