3 ms·

When asked about his opinion of the Apple M1 (which is heavily discussed recently on HN), Blow said it doesn’t matter in the long term, since software will even

by emsy 6y ago

When asked about his opinion of the Apple M1 (which is heavily discussed recently on HN), Blow said it doesn’t matter in the long term, since software will eventually eat up the performance improvements. It’s easy to get defensive about this argument since us programmers are the ones causing the problem. But as a user, I don’t want to need a 3 GHz machine to run a text editor somewhat responsively.

betareduce 6y ago
Fabien Senglard made a similar point [0] [0] https://fabiensanglard.net/silicone/index.html https://fabiensanglard.net/silicone/index.html
alpaca128 6y ago
> I don’t want to need a 3 GHz machine to run a text editor This annoys me as well. Visual Studio Code is about changing individual bytes in tiny plain text files. I don't think it has a single feature that didn't exist before. Yet its startup time is somehow closer to that of a full-fledged IDE, almost as long as the whole operating system needs to boot. Same with websites; a freshly configured email client can download a thousand messages from the server in a shorter period than it takes to load most news articles in the browser. And the most baffling thing to me is that such things are so widely accepted. I've seen many users shrugging it off with a "that's just how computers are" mindset; many things are implemented so badly people don't even expect them to work properly. This may sound a lot like "old man yells at cloud" material, but in the end it can't be denied performance is often at least an order of magnitude away from where it could be - my current laptop has 32 times as much RAM as my first PC, and it still swaps just as frequently.
- UncleMeat 6y ago
  > Visual Studio Code is about changing individual bytes in tiny plain text files. Only if you are being amazingly reductive. VSCode is about changing desirable sequences of bytes into more desirable sequences of bytes, where the definition of "desirable" is stupendously complex and depends on state that exists on many other computers around the world. If you just want to change bytes you can open notepad or nano and watch as they boot instantly. VSCode is much closer to Eclipse than nano in its capabilities. > And the most baffling thing to me is that such things are so widely accepted. To me I think about things like screen refresh rate or keyboard latency. Some people demand 120hz or incredibly low keyboard latency. But I'd wager that the percentage of people who care about such things are a rounding error. Even among hardcore gaming enthusiasts, optimal fps has only doubled over the past three decades. So there is way more real time to do stuff, and developers fill that time! They might fill it with features or they might fill it with lower development costs.
  - emsy 6y ago
    It’s true that VSCode is more than a simple byte changing tool. But the responsiveness is still unacceptable. A game reacts to my input virtually immediately while doing much more. Also, I have yet to see a proof of the increase in development efficiency. Personally, I think we have lowered the bar of entry more than we have increased developer efficiency, it’s follows that we see a decline in software quality.
  - alpaca128 6y ago
    > VSCode is much closer to Eclipse than nano in its capabilities. What exactly can it do that Vim or Emacs can't? Vim starts up literally 100 times faster on my machine, with 17 active plugins. It also runs everything in a single thread and is still more responsive than VSC in almost all scenarios. What are those stupendously complex features that somehow make a slow start unavoidable? Or to go with your comparison, why do you think Eclipse has a good reason to start so slowly, on a modern 8+ thread CPU and SSD?
    - fuyu 6y ago
      I very much prefer using Vim, but the debugging experience is much better in VSCode. The language server experience in VSCode is also better (though vim is getting there!), and there are many other small trade-offs that one may prefer. Emacs I haven't tried nearly as much, but it has a poor Windows OS experience, and is also historically a "bloated" software ("Eight Megabytes and Constantly Swapping"). Of course there is no reason Vim couldn't be modified to do everything VSCode does but better, but until that happens VSCode will still have a place in my toolbox.
- AnIdiotOnTheNet 6y ago
  > And the most baffling thing to me is that such things are so widely accepted. I've seen many users shrugging it off with a "that's just how computers are" mindset; many things are implemented so badly people don't even expect them to work properly. To me, this is the most damning evidence that our industry sucks at its job. We're so bad at making our products that users expect them to be slow and broken all the time.
fnord123 6y ago
Hardware performance is victim to Jevon's paradox. The M1 will result in more profligacy of cycles. Only battery life seems to have a chance of pushing performance the other way.

by emsy 6y ago

betareduce 6y ago

Fabien Senglard made a similar point [0] [0] https://fabiensanglard.net/silicone/index.html https://fabiensanglard.net/silicone/index.html

alpaca128 6y ago

> I don’t want to need a 3 GHz machine to run a text editor This annoys me as well. Visual Studio Code is about changing individual bytes in tiny plain text files. I don't think it has a single feature that didn't exist before. Yet its startup time is somehow closer to that of a full-fledged IDE, almost as long as the whole operating system needs to boot. Same with websites; a freshly configured email client can download a thousand messages from the server in a shorter period than it takes to load most news articles in the browser. And the most baffling thing to me is that such things are so widely accepted. I've seen many users shrugging it off with a "that's just how computers are" mindset; many things are implemented so badly people don't even expect them to work properly. This may sound a lot like "old man yells at cloud" material, but in the end it can't be denied performance is often at least an order of magnitude away from where it could be - my current laptop has 32 times as much RAM as my first PC, and it still swaps just as frequently.

UncleMeat 6y ago
> Visual Studio Code is about changing individual bytes in tiny plain text files. Only if you are being amazingly reductive. VSCode is about changing desirable sequences of bytes into more desirable sequences of bytes, where the definition of "desirable" is stupendously complex and depends on state that exists on many other computers around the world. If you just want to change bytes you can open notepad or nano and watch as they boot instantly. VSCode is much closer to Eclipse than nano in its capabilities. > And the most baffling thing to me is that such things are so widely accepted. To me I think about things like screen refresh rate or keyboard latency. Some people demand 120hz or incredibly low keyboard latency. But I'd wager that the percentage of people who care about such things are a rounding error. Even among hardcore gaming enthusiasts, optimal fps has only doubled over the past three decades. So there is way more real time to do stuff, and developers fill that time! They might fill it with features or they might fill it with lower development costs.
- emsy 6y ago
  It’s true that VSCode is more than a simple byte changing tool. But the responsiveness is still unacceptable. A game reacts to my input virtually immediately while doing much more. Also, I have yet to see a proof of the increase in development efficiency. Personally, I think we have lowered the bar of entry more than we have increased developer efficiency, it’s follows that we see a decline in software quality.
- alpaca128 6y ago
  > VSCode is much closer to Eclipse than nano in its capabilities. What exactly can it do that Vim or Emacs can't? Vim starts up literally 100 times faster on my machine, with 17 active plugins. It also runs everything in a single thread and is still more responsive than VSC in almost all scenarios. What are those stupendously complex features that somehow make a slow start unavoidable? Or to go with your comparison, why do you think Eclipse has a good reason to start so slowly, on a modern 8+ thread CPU and SSD?
  - fuyu 6y ago
    I very much prefer using Vim, but the debugging experience is much better in VSCode. The language server experience in VSCode is also better (though vim is getting there!), and there are many other small trade-offs that one may prefer. Emacs I haven't tried nearly as much, but it has a poor Windows OS experience, and is also historically a "bloated" software ("Eight Megabytes and Constantly Swapping"). Of course there is no reason Vim couldn't be modified to do everything VSCode does but better, but until that happens VSCode will still have a place in my toolbox.
AnIdiotOnTheNet 6y ago
> And the most baffling thing to me is that such things are so widely accepted. I've seen many users shrugging it off with a "that's just how computers are" mindset; many things are implemented so badly people don't even expect them to work properly. To me, this is the most damning evidence that our industry sucks at its job. We're so bad at making our products that users expect them to be slow and broken all the time.

fnord123 6y ago

Hardware performance is victim to Jevon's paradox. The M1 will result in more profligacy of cycles. Only battery life seems to have a chance of pushing performance the other way.