3 ms·
The problem is how we (devs) slowly but surely conditioned users (and even other, new coming devs) so that people don't even know how fast computers actually ar
by Xeamek 3y ago
The problem is how we (devs) slowly but surely conditioned users (and even other, new coming devs) so that people don't even know how fast computers actually are and how crazy it is that those things are as slow as they are.
So when it comes to performance, people don't even know that things could (should?) be exponentially faster.
- alkonaut 3y agoImagine the first bank where a monthly job took a roomful of smoking people took four days complete with calculators. In comes IBM and says "we can sell you a machine that does this in five minutes". Sure it'll weigh a ton and cost a fortune, but you'll see it's worth it. So they buy it. The machine performs half of 12 boring jobs at the bank needed every month. But there is still another half dozen jobs the IBM still cannot do. It doesn't have the punch cards. So the roomful of smokers does the rest of the jobs in a couple of weeks, ready just in time to start over with next months tasks. Should IBM make the machine or its programs twice as fast, or have twice as many features, even if the programs are half as fast? They should double the amount of features. And double it again, and again, and again...
- Xeamek 3y agoThat's the whole problem: With this local framing, it completely makes sense. But it's exactly the same with fossil fuels: Here and now, they are obvious choice with practically no downsides. But scale those "close to nothing" downsides times 7billion people, 100k seconds in a day, 365 days a week. And suddenly, the ammount of time and electricity alone wasted on something like, waitiing for windows explorer to start, adds to real world scales. ...But also, this implies that optimizing is inherently costly. Which is not always the case. Just the culutre of 'not caring' makes things go slower then they could, while still using the same high level languages etc.