[hdjjhhvvhga]

Only if there is an economic incentive to it. Currently, there is none. (A cynic in me would say the reverse is true at least in Apple ecosystem, as more resource-hungry apps push users to upgrade their devices more often.)

Moreover, I'm not sure how much you can gain, actually. You can probably get some reduction in app size as far as code segment is concerned, but usually most of the space is taken up by assets, especially in games, and they're already well compressed. So basically we could optimize the last 20% which are the hardest to get right.

[eru]

If we really needed to, we could compress assets a lot, eg with procedural generation. (Including the neural network kind.) But that would be a lot of hassle, and would probably trade run time for space.

As for code: I think shaving of bytes isn't all that important, especially compared to assets; but simplifying logic can give various benefits. However, that also takes time and is probably not worth it for many applications.

A distinction I like to make is being careful to distinguish between bloat that worsens throughput and bloat that worsens latency.

Throughput still gets better almost for free over time by general hardware improvements. Latency still requires attention.

An example: an early word processing software (I think it was part of GEOS for the Commodore 64) paid a lot of attention to keeping the latency between you pressing a key and a letter appearing on the screen low. By today's standards, the Commodore 64 was slow as molasses, so when you typed quickly GEOS eg temporarily disabled breaking wrapping words at the end of the line and just jumped to the next line in the middle of a word.

After you had finished your burst of typing, GEOS would go back and calculate proper line breaks.

Compare that with textfields in modern websites, which sometimes have a noticeable delay before a letter shows up.

GEOS's code for such latency reduction was probably incredible convoluted and messy (I am just guessing here) and made it hard to a nightmare to add new features, but was worth it back then. The modern bloated website can probably sustain a higher throughput, even without no one taking any care to optimize that. But latency is horrible.

[OhMeadhbh]

I wrote the PC equivalent for a similar product in the 1980s and wrote some different GEOS code. It was less convoluted than you might imagine. But it was very unforgiving in terms of de-referencing null pointers and memory leaks. Instead of using a little too much memory or causing a process to crash, it would often cause the system to hang. Windows 3 (and to a lesser degree Windows 95) had similar problems.

[ralphc]

In modern times the argument is the economic incentive is to optimize for the developer, not the hardware. Python, Node etc. over C.

[eru]

And most of the time that's the right trade-off.

Not all the time, though. Eg consider a video game: the image frames have to be pumped out on a tight time budget every couple of milliseconds, but the logic to decide whether you have finished your quest can afford to run for a few seconds in the background.

Even though the latter is much simpler and could probably be coded up to run on even the Timex m851 in fractions of a second.

[hnwizard]

I totally agree, there's no economic incentive, and sadly the "industry" will make sure complexity/size/scale will keep on growing. How much more performance and quantity do we need in CPU/RAM/storage/storage bandwidth for regular apps which I assume is the vast majority of computing at home/office.

Sure, games are ever-demanding and will continue going that way probably for a while longer especially on the pure graphics side.

Many apps do contain truck loads of libraries and dependencies, which have dependencies and all of that alone, accounts to massive code size.