4 ms·

> The result of that approach is that in 2023, our desktop is worse in usability and performance than what is was in 1998. I believe there are many more causes

> The result of that approach is that in 2023, our desktop is worse in usability and performance than what is was in 1998. I believe there are many more causes, some of them far more significant. Off the top of my head: * the Web and the related delays: people started to accept the fact that there is a small delay in everything they do related to network latency * the general "what Andy giveth Bill taketh away" mindset, and not just among MS developers: "if I have a powerful machine, I should use its full potential, and other people should do it, too" * the notion that programmer's time is more expensive than machine time * the notion that in order to win we need to be first, therefore there is no time to optimize things resource-wise * the belief that users only want features and don't care about speed * the lack of high-quality, developer-friendly, modern cross-platform UI framework resulting in many companies using Electron with its overhead

wiz21c 3y ago
> the notion that programmer's time is more expensive than machine time I do this computation each time I want to code something: time_to_develop + time_to_optimize + time_running and get the solution that minimizes that. Most of the time the optimize part is not worth it (although it'd be so much funnier to do it).
- vladvasiliu 3y ago
  I thin it's important to think about the context of "machine time". If "machine time" is some computer somewhere that only runs your code, then sure. Even as a customer, it might be cheaper to just pay more for a beefier machine than to pay more for optimizing the software. But when you're building human user-facing apps, you can't always just get a faster computer. As others have said, many instances of lag in windows can be traced to network calls. A 64-core monster would probably wait around just as long as my ultra-low voltage, several year-old lazy ultrabook.
- gbin 3y ago
  You should work in the gaming industry or robotics where if time_running > some constant you have no product.
  - wiz21c 3y ago
    I happen to work in the computational fluid dynamics department and I happen to have coded in the video game industry (optimized 3D engines). So I do know when optimizing is necessary. It's just that most of the time, for my computation, just waiting a few hours for a one-shot computation is much more effcient than spending 2 days optimizing it so that it runs in 20 minutes. But I admit my parent message was not quite clear on the context in which I was thinking :-)

wiz21c 3y ago

> the notion that programmer's time is more expensive than machine time I do this computation each time I want to code something: time_to_develop + time_to_optimize + time_running and get the solution that minimizes that. Most of the time the optimize part is not worth it (although it'd be so much funnier to do it).

vladvasiliu 3y ago
I thin it's important to think about the context of "machine time". If "machine time" is some computer somewhere that only runs your code, then sure. Even as a customer, it might be cheaper to just pay more for a beefier machine than to pay more for optimizing the software. But when you're building human user-facing apps, you can't always just get a faster computer. As others have said, many instances of lag in windows can be traced to network calls. A 64-core monster would probably wait around just as long as my ultra-low voltage, several year-old lazy ultrabook.
gbin 3y ago
You should work in the gaming industry or robotics where if time_running > some constant you have no product.
- wiz21c 3y ago
  I happen to work in the computational fluid dynamics department and I happen to have coded in the video game industry (optimized 3D engines). So I do know when optimizing is necessary. It's just that most of the time, for my computation, just waiting a few hours for a one-shot computation is much more effcient than spending 2 days optimizing it so that it runs in 20 minutes. But I admit my parent message was not quite clear on the context in which I was thinking :-)