> The idea that your code cannot be beautiful unless you use system knowledge to optimize it "within an order of magnitude [of] the most performant possible cod

> The idea that your code cannot be beautiful unless you use system knowledge to optimize it "within an order of magnitude [of] the most performant possible code", before you even know there is a noticeable performance problem with it, is bad advice. I disagree, but the key phrase here is "within an order of magnitude." I don't think it refers to squeezing out CPU cycles but rather to choosing the right general solution. Using a cursor in sql when you don't need to is ugly programming whether or not the specific module has a real-world performance problem or not. Similarly, looping multiple times through a singly-linked-list when a hashset was called for is ugly code as well, regardless if that particular method has a significant real-world effect on performance. I'm not sure we really disagree here except on semantics. Choosing the right data structure or language idiom for the job at hand isn't premature optimization, at least not the kind that should be avoided, and it's essential to beautiful code IMO.