4 ms·

I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly

I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).

goodlinks 4y ago
Externalised cost on the environment will hopefully one day be addressed.
- TeMPOraL 4y ago
  Not to mention the users. For all the bullshit the marketing departments of every company spew about valuing their customers, software companies don't really give a damn about the many person-hours of users' lives they waste to save a person-minute of dev time.
  - davnicwil 4y ago
    Everything is a balance though, and the tradeoff may not be linear. Where they've landed on it may be the only way to get the software to customers at all in a cost effective manner.
pkolaczk 4y ago
> developer time is a significantly more expensive resource than compute Depends on the number of invocations of the program.
- MonkeyClub 4y ago
  Not just that. The “developer time is valuable” mantra is thrown left and right, disregarding how much of that valuable resource will be wasted down the line due to bad implementations. If we optimize for developer time, let’s optimize across the software’s entire lifecycle, not just that first push of a MVP to production.
  - cinntaile 4y ago
    This is a good point but it gets complicated as you often don't know the software's entire lifecycle so you have to optimize for something slightly different.
    - MonkeyClub 4y ago
      Yep, I think you’re right. We just need to do away with shoddy first implementations, while avoiding premature optimization (or pointless perfectionism). Which is all good in theory. In practice, management needs to also acquiesce and stop with the impossible deadlines. I mean, I’ve worked on more than one projects that were sold to clients before they were implemented, and I think I’m not unique in that :)
zaphodias 4y ago
Yeah you're right, nobody ever said to me "use interfaces because the code it's faster". On the other hand, when I studied dynamic dispatch and stuff like that, I don't think enough people told me "when you do that, you are making this tradeoff". I feel like it's worth sharing this kind of knowledge in order to make better informed decisions (possibly based on numbers). There's no need to become an extremist in either direction.
- jesstaa 4y ago
  The trade off has changed over time as memory access has become a bigger and bigger bottleneck. But caring about this is still "premature optimisation". The claim of 20x program performance difference is overblown. Compilers can often remove virtual function calls, JITs can also do it at runtime. Virtual function calls in a tight loop are slow but most of your program isn't in a tight loop and few programs have compute as a bottleneck. Measure your program, find the tight loops in your program and optimise that small part of your program.
AnIdiotOnTheNet 4y ago
I think this is hilarious when talking about someone like Muratori, who has had his hands in more games' code than most people on this site have ever even played. He is incredibly productive by comparison to all the people making excuses why their programs are slow bloated garbage fires.
kps 4y ago
The context for the author is game development. A game can't just spin up a few more servers in the cloud. The slower the code, the smaller the customer base. Some fields have more severe constraints, where developer time may be expensive, but compute is priceless. (This is not to endorse writing code that is harder than necessary to understand, or failing to document the parts that are necessarily hard.)
- adamrezich 4y ago
  this video is part of a course that is not at all specific to game development, in any way whatsoever—where do these excuses come from?
sicp-enjoyer 4y ago
> developer time is a significantly more expensive resource than compute This also presupposes that making a fast program is a lot more work. However poor performance is usually due to negligence rather than a lack of optimization effort. All you need to write reasonably fast code by default (without micro-optimizing) is: 1. a good knowledge of available algorithms 2. a good understanding of the problem 1. Is a one-time investment on the programmers part that benefits all future programs they write. There is no marginal cost to being familiar with what's available in <algorithm>. 2. Has a marginal cost, but it's probably a time saver anyway. Measure once, cut twice.

goodlinks 4y ago

Externalised cost on the environment will hopefully one day be addressed.

TeMPOraL 4y ago
Not to mention the users. For all the bullshit the marketing departments of every company spew about valuing their customers, software companies don't really give a damn about the many person-hours of users' lives they waste to save a person-minute of dev time.
- davnicwil 4y ago
  Everything is a balance though, and the tradeoff may not be linear. Where they've landed on it may be the only way to get the software to customers at all in a cost effective manner.

pkolaczk 4y ago

> developer time is a significantly more expensive resource than compute Depends on the number of invocations of the program.

MonkeyClub 4y ago
Not just that. The “developer time is valuable” mantra is thrown left and right, disregarding how much of that valuable resource will be wasted down the line due to bad implementations. If we optimize for developer time, let’s optimize across the software’s entire lifecycle, not just that first push of a MVP to production.
- cinntaile 4y ago
  This is a good point but it gets complicated as you often don't know the software's entire lifecycle so you have to optimize for something slightly different.
  - MonkeyClub 4y ago
    Yep, I think you’re right. We just need to do away with shoddy first implementations, while avoiding premature optimization (or pointless perfectionism). Which is all good in theory. In practice, management needs to also acquiesce and stop with the impossible deadlines. I mean, I’ve worked on more than one projects that were sold to clients before they were implemented, and I think I’m not unique in that :)

zaphodias 4y ago

Yeah you're right, nobody ever said to me "use interfaces because the code it's faster". On the other hand, when I studied dynamic dispatch and stuff like that, I don't think enough people told me "when you do that, you are making this tradeoff". I feel like it's worth sharing this kind of knowledge in order to make better informed decisions (possibly based on numbers). There's no need to become an extremist in either direction.

jesstaa 4y ago
The trade off has changed over time as memory access has become a bigger and bigger bottleneck. But caring about this is still "premature optimisation". The claim of 20x program performance difference is overblown. Compilers can often remove virtual function calls, JITs can also do it at runtime. Virtual function calls in a tight loop are slow but most of your program isn't in a tight loop and few programs have compute as a bottleneck. Measure your program, find the tight loops in your program and optimise that small part of your program.

AnIdiotOnTheNet 4y ago

I think this is hilarious when talking about someone like Muratori, who has had his hands in more games' code than most people on this site have ever even played. He is incredibly productive by comparison to all the people making excuses why their programs are slow bloated garbage fires.

kps 4y ago

The context for the author is game development. A game can't just spin up a few more servers in the cloud. The slower the code, the smaller the customer base. Some fields have more severe constraints, where developer time may be expensive, but compute is priceless. (This is not to endorse writing code that is harder than necessary to understand, or failing to document the parts that are necessarily hard.)

adamrezich 4y ago
this video is part of a course that is not at all specific to game development, in any way whatsoever—where do these excuses come from?

sicp-enjoyer 4y ago

> developer time is a significantly more expensive resource than compute This also presupposes that making a fast program is a lot more work. However poor performance is usually due to negligence rather than a lack of optimization effort. All you need to write reasonably fast code by default (without micro-optimizing) is: 1. a good knowledge of available algorithms 2. a good understanding of the problem 1. Is a one-time investment on the programmers part that benefits all future programs they write. There is no marginal cost to being familiar with what's available in <algorithm>. 2. Has a marginal cost, but it's probably a time saver anyway. Measure once, cut twice.