3 ms·
I use a reasonably beefy machine to develop “heavy” desktop software. It’s definitely the kind discussed in this article. I find it frustrating that it has noti
by alkonaut 3y ago
I use a reasonably beefy machine to develop “heavy” desktop software. It’s definitely the kind discussed in this article. I find it frustrating that it has noticeable input lag even with moderate workloads for exactly the reasons mentioned.
But then you talk to end users and it turns out they work 80 hours on one big document with input lag of several seconds. Some actions can take 15 seconds. It’s mad. It’s larger than anything we imagined anyone to work on. It must be infuriating. And they don’t get beefier machines despite it being an instant cost saving. Because software is seen as magical anyway. They do in two days what would take 50 days to calculate by hand! That’s fast! So when you ask them what to prioritize surely they say “make it faster with heavy documents”?
No, they want more features. Because a feature can save then days or weeks or months. A faster program just saves them hours. So I sort of understand them (and why we build software that grows slow).
- HeyLaughingBoy 3y agoAnd this is exactly why you talk to users. You get the most unexpected feedback that you'd never have guessed in a million years.
- Xeamek 3y agoThe 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.