3 ms·

But in your example, your only describing one specific task (n=1). The issue is that time accumulates non linearly as the number of tasks increase. i.e the petr

But in your example, your only describing one specific task (n=1). The issue is that time accumulates non linearly as the number of tasks increase. i.e the petrol stations must be able to supply enough petrol to all customers that drive the most inefficient car. The culture of "developer time is most important", makes overall system performance someone else's problem, because "my program is fast enough when I measure it off the wall clock". But who's responsible to fix overall system performance, and how can they fix it? I think a lot of people would just upgrade their RAM, CPU or IO to solve the issue (create more petrol stations), rather than asking vendors to change the programming language, or to be more conservative on RAM. And because there's costs to switching language stacks, people will stick to writing in the language they are comfortable in, so critical business systems get written in slow languages.

coldtea 7y ago
>But in your example, your only describing one specific task (n=1). That's to maintain parity with the example TFA gives. I'm not saying it's never worth it... Of course you'll optimize often repeated tasks, loops, etc. Here's what TFA quotes as bad reasoning, because it makes fun of optimization effort in some cases: "@tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days :-)" Unlike TFA I agree with the twitting guy above that the efficiency improvement here wasn't worth it.
- juststeve 7y ago
  Yeah agreed. i mean in that example, if tveastman wrote it in a fast language the first time, the rewrite probably wouldn't have been required. (i think that tweet was for a bit of a laugh anyway, because he can now write new code in Rust.) But as many languages support implicit static typing, the folklore that dynamic languages are "more expressive" is not actually correct. such as: let x = "string literal" //compiled as string let y = 42 //compiled as int let z : i32 = 100 //compiled with type declared as 32 bit int.

coldtea 7y ago

>But in your example, your only describing one specific task (n=1). That's to maintain parity with the example TFA gives. I'm not saying it's never worth it... Of course you'll optimize often repeated tasks, loops, etc. Here's what TFA quotes as bad reasoning, because it makes fun of optimization effort in some cases: "@tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days :-)" Unlike TFA I agree with the twitting guy above that the efficiency improvement here wasn't worth it.

juststeve 7y ago
Yeah agreed. i mean in that example, if tveastman wrote it in a fast language the first time, the rewrite probably wouldn't have been required. (i think that tweet was for a bit of a laugh anyway, because he can now write new code in Rust.) But as many languages support implicit static typing, the folklore that dynamic languages are "more expressive" is not actually correct. such as: let x = "string literal" //compiled as string let y = 42 //compiled as int let z : i32 = 100 //compiled with type declared as 32 bit int.