> but now you have a function call per renormalization and that has a cost that may be unacceptable.
I would go for the function, and pass along Knuth's advice about premature optimization. If you're writing at such a low level that function calls actually aren't acceptable, go with a comment "// renormalize vector." Your instinct should be the function though. I bet there is more than one vector normalization going on in this hypothetical codebase, and that line looks pretty typo-prone.
> I disable the flash on every piece of camera equipment I own. In my book, there is never a scenario where it is okay to use a flash, if it is too dark to take the photo, then don’t take it.
I think the fact that you (and I) don't trust current camera flashes to make photos worth keeping is actually an argument that it's a problem worth fixing. It remains to be seen how successful the 5S flash will be, but I think it's cool they're trying. I'm also glad Apple made the sensor elements larger rather than cramming in more mega pixels. Normally that's a concern of the geeky DSLR consumers, and point & shooters suffer with noisy low-light performance and more pixels than they need.
I recently read Software Estimation (Steve McConnell, author of Code Complete). My main takeaway was to distrust developer intuition and instead build estimates from data. One example is to look at the duration of past projects of "similar size" (still requires some qualitative analysis). Another example is to count the number of distinct "features" or "components," and build an estimate from those. Both of these still require some qualitative analysis. That will be the weak point of any estimate. The goal is to minimize inputs from developer intuition and use as much quantitative analysis as possible when estimating.
> A scientist isn't committed to believing in natural selection in the same way a bibilical literalist is committed to rejecting it. All he's committed to is following the evidence wherever it leads.
At the risk of responding out of identity, but also with the hope of contributing constructively despite having some identity at stake:
A literal interpretation of the bible doesn't preclude accepting natural selection as an ongoing, observable process. It may reject that process as the explanation of our species' origins. Those two are often conflated, contributing to the identity-driven, emotion-filled discussion that PG describes.
Regarding the main premise of the article, I think it's possible to have rational, logical discussions about topics in which identity is involved. They are more challenging than, say, discussing Javascript. But I don't think those discussions work well on the internet. They require trust (that both parties will be heard in good faith) careful check of emotions, motivations, and reasoning. Those are even more challenging without high-bandwidth communication aids like facial expressions and tone of voice.
I think the problem is that software / algorithm patents have broader implications and abuses than patents for chemical formulas. They are also being granted for topics that many would consider obvious to those active in the field. The issue isn't protecting valid and specific invention from copying, it's the ease with which software / algorithm patents can be used to sue / bully others with legitimate (not copied) creative inventions. I think the ephemeral nature of software makes it inevitable that a patent eventually gets approved by an examiner if resubmitted enough times. A bogus chemical patent is probably easier to prove bogus.
I would go for the function, and pass along Knuth's advice about premature optimization. If you're writing at such a low level that function calls actually aren't acceptable, go with a comment "// renormalize vector." Your instinct should be the function though. I bet there is more than one vector normalization going on in this hypothetical codebase, and that line looks pretty typo-prone.