3 ms·

Performance can absolutely come from the programmer. It's a question of defaults. One can default to correctness and opt-in to performance (in the places wher

Performance can absolutely come from the programmer. It's a question of defaults. One can default to correctness and opt-in to performance (in the places where critically needed, often a small portion of the program) much more easily than one can default to performance and opt-in to correctness.

dahfizz 3y ago
> Performance can absolutely come from the programmer. To a point, sure. But your language and tools dictate a upper bound on speed. You are never going to get a trading app written in Python to be faster than your competitor's app written in C.
deleted 3y ago
[deleted]
kazinator 3y ago
Yes, performance does come from how a program is written, like choice of data structures and algorithms. But performance is also - defined by fairly simple, measurable parameters that everyone agrees on, like execution time, code size or memory use; - subject to automation: compilers can take a program which, if run literally as written, is slow, and speed it up. (Or make it smaller or require less memory.) Correctness is not like this. - There is no universal definition of correctness; it is the degree to which a program matches its arbitrary specification. - Compilers cannot take a program that is incorrect and optimize it to have more correctness. They don't read the specification. If I ask someone to write a program which demonstrates how a null pointer deference results in a predictable segmentation fault, then this will be a correct program: int main(void} { *((char *) NULL) = 0; } A correct program could crash in this way even none of its requirements say that it should exercise null dereference or any other error on purpose. A correct program could be given incorrect data, for which its behavior is not specified. The program is then being misused; the ill behavior doesn't demonstrate that it's incorrect. A program which has no requirements for handling unexpected inputs, and does not do so, cannot be safely deployed in certain situations, like when it runs in one security domain, but inputs are coming from a different one. That situation implicitly adds requirements, which that program does not meet; effectively the program is interpreted as incorrect. That shows that there can be misunderstandings and disagreements about what is correct, which boils down to disagreeing on what is and isn't a requirement. We would never disagree that a program which calculates something in 3 seconds is faster (on that input case) than one which does the same in 5 seconds. (All else being same; hardware, OS, ...)

dahfizz 3y ago

> Performance can absolutely come from the programmer. To a point, sure. But your language and tools dictate a upper bound on speed. You are never going to get a trading app written in Python to be faster than your competitor's app written in C.

deleted 3y ago

[deleted]

kazinator 3y ago

Yes, performance does come from how a program is written, like choice of data structures and algorithms. But performance is also - defined by fairly simple, measurable parameters that everyone agrees on, like execution time, code size or memory use; - subject to automation: compilers can take a program which, if run literally as written, is slow, and speed it up. (Or make it smaller or require less memory.) Correctness is not like this. - There is no universal definition of correctness; it is the degree to which a program matches its arbitrary specification. - Compilers cannot take a program that is incorrect and optimize it to have more correctness. They don't read the specification. If I ask someone to write a program which demonstrates how a null pointer deference results in a predictable segmentation fault, then this will be a correct program: int main(void} { *((char *) NULL) = 0; } A correct program could crash in this way even none of its requirements say that it should exercise null dereference or any other error on purpose. A correct program could be given incorrect data, for which its behavior is not specified. The program is then being misused; the ill behavior doesn't demonstrate that it's incorrect. A program which has no requirements for handling unexpected inputs, and does not do so, cannot be safely deployed in certain situations, like when it runs in one security domain, but inputs are coming from a different one. That situation implicitly adds requirements, which that program does not meet; effectively the program is interpreted as incorrect. That shows that there can be misunderstandings and disagreements about what is correct, which boils down to disagreeing on what is and isn't a requirement. We would never disagree that a program which calculates something in 3 seconds is faster (on that input case) than one which does the same in 5 seconds. (All else being same; hardware, OS, ...)