>>12325379It's more that optimization takes time and skill, both of which are things that devs expect to be paid for, which cuts into their superiors' profit margins. Frameworks tend to cut the development time down at the expense of having to include a bunch of functionality that may go unused. And sometimes, real-time performance is more important than size on-disk which is why it's often more sensible to store a bunch of lookup tables (for multimedia content, that includes things like audio and image files) instead of generating it all at runtime.
Also consider that a lot of what makes humans function (or any form of life, really) boils down to simple biochemical processes which are beholden to the laws of nature; there's no need to program human behaviour into each individual's DNA, for example. Most of what you are and do is just emergent behaviour arising from the interaction of submicroscopic particles that, at a small enough scale, is indistinguishable from any other subatomic interaction. Consider the difference between programming a graphical text editor for a microprocessor-based system for which no firmware or software exists, and writing a graphical text editor in a high-level language using a GUI framework. In the former case, you're going to produce tons and tons of dependency code for graphics handling, interpreting hardware signals in the software, passing those through to your program, handling them appropriately, etc. In the latter case, the program could be reduced to a few kilobytes of actual functionality and a few kilobytes in a markup language that describes the graphical layout; everything else is handled by the target operating system, the system libraries etc, none of which are part of your text editor.
Love, /g/
