6 ms·

I don't think this is mostly true. Many classes of applications are running perceptively similar to before but accomplishing much more. Easiest example is game

by TwoBit 6y ago

I don't think this is mostly true. Many classes of applications are running perceptively similar to before but accomplishing much more. Easiest example is game software. But it’s true enough for web browser software if you can extract the crippling effect of today's ad networks (which many people do via a plugin).

ryandrake 6y ago
Are they really accomplishing that much more? Or are they being used to create and destroy containers of ClassFactoryProxyBuilders over and over? The topic reminds me of “24 Core CPU and I Can’t Move My Mouse” [1]. We deploy faster and faster hardware and use it for what? For holding global locks, iterating through object tables and navigating through abstraction after abstraction until the call stack is 100 calls deep. My word processor today is about as UI responsive as MS Word was in the 90’s and I use pretty much the same features now as I did before. Visual Studio Code’s UI is noticeably slower on my modern CPU than Visual C++ 6 was 30 years ago, although to be fair it compiles much faster today. 1: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/ https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...
- outsomnia 6y ago
  > abstraction after abstraction until the call stack is 100 calls deep. If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. Web browsers run insanely stable over very long periods of time when you consider what's under to hood.
  - lmm 6y ago
    Yep. Remember how often Word would crash in the '90s? We were warned to save our work regularly lest it be lost. Make it work, then make it right, then make it fast. We shouldn't even begin to worry about performance until we've got a handle on correctness, and frankly software in general isn't there yet.
    - TeMPOraL 6y ago
      That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. Also, arguably, auto-saving existed in 90s - and the primary reasons it wasn't as nice as it was today were UX (wasn't enabled by default IIRC) and hardware (spinning rust wasn't good enough to support transparent auto-saving every other second).
      - lmm 6y ago
        > That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. So do crashes, and so especially does silently outputting the wrong answer. Slow but reliable beats fast but flaky every time, and it's much easier to speed up a working program than fix a flaky one.
  - TeMPOraL 6y ago
    > If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. It's not? Consider: to make your workflow easier, you impose costs - real costs, in both emotions and money - on every single one of your users. And the more users you gain, the more the society ultimately pays for a fixed benefit of making it easier for your team to do the work. To some degree, this trade-off is necessary, but I propose that it's absolutely crazy to consider taking it unless it is necessary.
Tepix 6y ago
> ... but accomplishing much more. Easiest example is game software. Ha! Are you saying the old games that ran faster didn't bring us joy?
- maccard 6y ago
  I think that's a really disingenuous reply. He's clearly saying that the processing power advancements have shown significantly in games;commodity hardware now performs real time ray tracing in 3d in a photorealistic depiction of a real life city for not-much-more-dollar-cost than the N64 did when it was launched 25 years ago. Whether it brings you more joy or is more/less fun is irrelevant
  - Tepix 6y ago
    It was a tongue-in-cheek reply of course, but there's some truths to it. Just like 4K resolution doesn't make movies better, adding raytracing or fancy shadows doesn't turn a bad game into something that's more fun than, say the Super Mario Bros. (1985, 31KByte) on NES (2KB RAM) which sold 40 million copies. We need to question ourselves every now and then why we are adding things like cutting edge graphics to games (and adding complexity in general). Which is what this article is about.
TeMPOraL 6y ago
That's nice that you mention games, because they're a great baseline for what your hardware can do. I personally use it as a sanity check. I look at the amount of data processing the software I'm building does, compare it mentally against the amount of data processing a random videogame from 10 years ago did, and ask myself (and the team), how come our software does much less work than that game, and runs much slower than that game did a decade ago? (And the answer very often boils down to: lots of unnecessary parsing or string processing, and bad choices in data structures. Both relatively easily fixable, if one bothers to look for it - and both mistakes that could have been avoided in the first place at little to no cost in developer effort.)

by TwoBit 6y ago

ryandrake 6y ago

Are they really accomplishing that much more? Or are they being used to create and destroy containers of ClassFactoryProxyBuilders over and over? The topic reminds me of “24 Core CPU and I Can’t Move My Mouse” [1]. We deploy faster and faster hardware and use it for what? For holding global locks, iterating through object tables and navigating through abstraction after abstraction until the call stack is 100 calls deep. My word processor today is about as UI responsive as MS Word was in the 90’s and I use pretty much the same features now as I did before. Visual Studio Code’s UI is noticeably slower on my modern CPU than Visual C++ 6 was 30 years ago, although to be fair it compiles much faster today. 1: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/ https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...

outsomnia 6y ago
> abstraction after abstraction until the call stack is 100 calls deep. If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. Web browsers run insanely stable over very long periods of time when you consider what's under to hood.
- lmm 6y ago
  Yep. Remember how often Word would crash in the '90s? We were warned to save our work regularly lest it be lost. Make it work, then make it right, then make it fast. We shouldn't even begin to worry about performance until we've got a handle on correctness, and frankly software in general isn't there yet.
  - TeMPOraL 6y ago
    That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. Also, arguably, auto-saving existed in 90s - and the primary reasons it wasn't as nice as it was today were UX (wasn't enabled by default IIRC) and hardware (spinning rust wasn't good enough to support transparent auto-saving every other second).
    - lmm 6y ago
      > That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. So do crashes, and so especially does silently outputting the wrong answer. Slow but reliable beats fast but flaky every time, and it's much easier to speed up a working program than fix a flaky one.
- TeMPOraL 6y ago
  > If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. It's not? Consider: to make your workflow easier, you impose costs - real costs, in both emotions and money - on every single one of your users. And the more users you gain, the more the society ultimately pays for a fixed benefit of making it easier for your team to do the work. To some degree, this trade-off is necessary, but I propose that it's absolutely crazy to consider taking it unless it is necessary.

Tepix 6y ago

> ... but accomplishing much more. Easiest example is game software. Ha! Are you saying the old games that ran faster didn't bring us joy?

maccard 6y ago
I think that's a really disingenuous reply. He's clearly saying that the processing power advancements have shown significantly in games;commodity hardware now performs real time ray tracing in 3d in a photorealistic depiction of a real life city for not-much-more-dollar-cost than the N64 did when it was launched 25 years ago. Whether it brings you more joy or is more/less fun is irrelevant
- Tepix 6y ago
  It was a tongue-in-cheek reply of course, but there's some truths to it. Just like 4K resolution doesn't make movies better, adding raytracing or fancy shadows doesn't turn a bad game into something that's more fun than, say the Super Mario Bros. (1985, 31KByte) on NES (2KB RAM) which sold 40 million copies. We need to question ourselves every now and then why we are adding things like cutting edge graphics to games (and adding complexity in general). Which is what this article is about.

TeMPOraL 6y ago

That's nice that you mention games, because they're a great baseline for what your hardware can do. I personally use it as a sanity check. I look at the amount of data processing the software I'm building does, compare it mentally against the amount of data processing a random videogame from 10 years ago did, and ask myself (and the team), how come our software does much less work than that game, and runs much slower than that game did a decade ago? (And the answer very often boils down to: lots of unnecessary parsing or string processing, and bad choices in data structures. Both relatively easily fixable, if one bothers to look for it - and both mistakes that could have been avoided in the first place at little to no cost in developer effort.)