4 ms·

> 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

> 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.

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.