Now you just need to design a balanced ternary computer which uses lambda calculus instead of Boolean logic and you will be a quarter of the way to getting rid of the gunk left over from the birth of computers when people were arguing if relays or vacuum tubes were the way of the future.
The one thing I have noticed all the people with "philosophical" objections to bloat have in common is that they are largely ignorant of the real hardware and software they are coding on. This was brought nowhere better to the front than in this video https://www.youtube.com/watch?v=Nbv9L-WIu0s where they showed that the tools written because gnu tools were too big when measured in a running computer take up just as many resources.
There appears to be some discrepancy in the interpretation and use of some terminology.
To clarify, what many of us refer to as bloat has nothing at all to do with run time resource usage, but instead relates to unnecessary features and complexity. We see freedom and beauty in short, clean, simple code, small utilities and terse specifications. These are seldom the most efficient (computationally) solution to any particular problem, but these tools are small (in terms of code, possibly binary), and therefore easy to implement and maintain as well as understand. And we can easily replace such tools if necessary; we don't become excessively dependent on giant code bases. When computational resources permit it, we prefer to get rid of optimizations to simplify these tools internally.
A bloated tool might have a million features, it can be many times as efficient at some things, it can probably do more. But it is likely to be hard to modify, a pain to maintain, difficult to port, and diagnosing problems gets harder with more complicated tools. As soon as you start using half of its features, you become very dependent on that particular tool. And you probably cannot replace it, it would be too much work. Your freedom suffers.
More often than not, we can get our jobs done with simple and small tools. Thus the big and complicated tool is filled with unnecessary things; it is bloated.
>This was brought nowhere better to the front than in this video https://www.youtube.com/watch?v=Nbv9L-WIu0s where they showed that the tools written because gnu tools were too big when measured in a running computer take up just as many resources.
At what time in the video does that happen? I didn't have time to watch the whole thing, but it doesn't appear that what you are suggesting was even brought up much less demonstrated?
They're just measuring code size and such. Kilobytes that do not really matter, unless you're embedded.
Right near the end they present some minimal tools that are supposed to have no bloat because they're written in assembly and don't need libc. Turns out these aren't any better than gnu tools with dietlibc, after some shaving.
Not really worth watching through, if you were expecting discussion about real bloat. I think they're just setting up a straw man, a bad one at that too.
The one thing I have noticed all the people with "philosophical" objections to bloat have in common is that they are largely ignorant of the real hardware and software they are coding on. This was brought nowhere better to the front than in this video https://www.youtube.com/watch?v=Nbv9L-WIu0s where they showed that the tools written because gnu tools were too big when measured in a running computer take up just as many resources.