4 ms·

On a high level, computing requirements don’t change that much; the biggest problem is our entire ecosystem’s expectations is growing as fast as our hardware ga

On a high level, computing requirements don’t change that much; the biggest problem is our entire ecosystem’s expectations is growing as fast as our hardware gains in performance. It’s the mentality of the software industry as a whole. Making both pretty and lean versions of the same app is never an option; typically one just makes an electron app and calls it a day. Games are exempt from this and seem to typically target a large variety of hardware. I don’t know who started this, though. Whether it was the consumers who started buying new computer hardware much more frequently than they are buying drill machines, or the software vendors gradually bloating their apps forcing users to upgrade their hardware. But it seems to be state that we’re in.

rabidrat 7y ago
Moore's Law is responsible. Computers in the 80s were much more modifiable and long-lasting, but back then 5 years was an absolute eternity for hardware performance. So we learned to buy cheaper computers because we'd have to replace them every 3-5 years anyway.
fao_ 7y ago
> Making both pretty and lean versions of the same app is never an option To clarify this point, it is entirely an option. Most of the layout done with CSS, etc. these days could absolutely render on older machines if built using different tools. The problem is that a) people want to build it with what they are familiar with, which these days is web tech. That means that those specific abstractions do not exist in that space, and b) very few people these days have the skill, funding, and time to build those abstractions.
mntmoss 7y ago
A lot of the bloat is derived from overarching platform features. A 1980's application had to live on its own and communicate mostly in printed English documents. Many of those early microcomputer apps were therefore glorified printer drivers with a bit of disk or tape I/O. Everything ASCII or with a regional code page - very simple. Then we added multitasking, networking, UTF localization, variable and multi-display support, multimedia, accessibility and so on. These features add value but as you say, raise expectations - and so create subtle additional costs. We built frameworks and standard APIs to deal with each thing as it came along. The platforms got bigger, much much bigger. And the hardware profiles have shifted as well. 64-bit support adds a lot of bloat for an application that doesn't need a huge address space. Games are often immune to these things since the final runtime is mostly "viewing" and not "editing", so their requirements are more focused, but they also get hindered by platform abstractions. Only console games can even consider taking direct control over I/O; everyone else has to go through some kind of API, even if it's the operating system's lowest level API. There's all kinds of buffering and sandboxing in consumer operating systems that is OK for media playback, but not for interactivity. Games historically act as bellwether "killer apps" - soaking up resources to deliver basically the same kinds of experiences at ever-higher fidelity, which justifies purchasing higher end gear. Then the apps follow, making use of the new install base. Things that were products gradually turn into standardized features. There is some kind of endpoint, or perhaps reset point, to all this - when the experience is already at peak fidelity, other forms of differentiation start to set in. New apps regularly appear as the "small minimalist alternative" to a old long-in-the-tooth standard. The new kid gets bigger to cover more users. Then it becomes the old standard, and the cycle repeats. With some products this is a very long cycle - Word and Photoshop are still viable. Others come and go. But it's basically true outside of software too. Nails and screws used to be extremely valuable and difficult to manufacture, and now they are simple components - their role changed from being the product to being the feature.

rabidrat 7y ago

Moore's Law is responsible. Computers in the 80s were much more modifiable and long-lasting, but back then 5 years was an absolute eternity for hardware performance. So we learned to buy cheaper computers because we'd have to replace them every 3-5 years anyway.

fao_ 7y ago

> Making both pretty and lean versions of the same app is never an option To clarify this point, it is entirely an option. Most of the layout done with CSS, etc. these days could absolutely render on older machines if built using different tools. The problem is that a) people want to build it with what they are familiar with, which these days is web tech. That means that those specific abstractions do not exist in that space, and b) very few people these days have the skill, funding, and time to build those abstractions.

mntmoss 7y ago

A lot of the bloat is derived from overarching platform features. A 1980's application had to live on its own and communicate mostly in printed English documents. Many of those early microcomputer apps were therefore glorified printer drivers with a bit of disk or tape I/O. Everything ASCII or with a regional code page - very simple. Then we added multitasking, networking, UTF localization, variable and multi-display support, multimedia, accessibility and so on. These features add value but as you say, raise expectations - and so create subtle additional costs. We built frameworks and standard APIs to deal with each thing as it came along. The platforms got bigger, much much bigger. And the hardware profiles have shifted as well. 64-bit support adds a lot of bloat for an application that doesn't need a huge address space. Games are often immune to these things since the final runtime is mostly "viewing" and not "editing", so their requirements are more focused, but they also get hindered by platform abstractions. Only console games can even consider taking direct control over I/O; everyone else has to go through some kind of API, even if it's the operating system's lowest level API. There's all kinds of buffering and sandboxing in consumer operating systems that is OK for media playback, but not for interactivity. Games historically act as bellwether "killer apps" - soaking up resources to deliver basically the same kinds of experiences at ever-higher fidelity, which justifies purchasing higher end gear. Then the apps follow, making use of the new install base. Things that were products gradually turn into standardized features. There is some kind of endpoint, or perhaps reset point, to all this - when the experience is already at peak fidelity, other forms of differentiation start to set in. New apps regularly appear as the "small minimalist alternative" to a old long-in-the-tooth standard. The new kid gets bigger to cover more users. Then it becomes the old standard, and the cycle repeats. With some products this is a very long cycle - Word and Photoshop are still viable. Others come and go. But it's basically true outside of software too. Nails and screws used to be extremely valuable and difficult to manufacture, and now they are simple components - their role changed from being the product to being the feature.