First of all, if comments lie, so do function names. So refactoring to replace all your comments with function-names is a waste of time. The same goes for variable names; the difference is that you were presumably going to have variables in your code anyway.
More constructive commenting advice:
If your comments are supposed to explain what the code does, give a few extra minutes to considering whether the code could be clearer (some tasks might require complicated code that merits comments, but most tasks can be accomplished with self-explanatory code).
On the other hand, sometimes there are external reasons, not enscapulated within your code, why you must do something surprising. This unequivocally merits comments. "I did this because of RFC #XYZ" or "Partner FooCorp needs this bizarre format, see /global/path/to/spec", or "our data has such-and-such a distribution, thus this surprising approach, which improves the 99th %ile latency".
>First of all, if comments lie, so do function names. So refactoring to replace all your comments with function-names is a waste of time
This isn't my experience at all. Comments don't need to be read, therefore the programmer has a greater chance of not realizing they are now out of sync with the code (this can happen on a project you're completely familiar with). Function and variable names must be read and comprehended to use, so it is much more likely that any divergence will be picked up. I completely agree with the author that descriptive function and variable names are much more valuable than comments, and thus the former should be heavily favored.
Not only that, but in the last example in that section he replaces a fairly short and readable expression with a function call. I don't see how this is different than a comment in any meaningful way (except that it requires extra lines of boilerplate and whitespace that don't lift any explanatory weight), and unlike a comment it pollutes the call stack for no good reason.
The call stack is cheap, its your mental stack that you should be trying to optimize for. Any label over a set of operations (even a single expression) will reduce the mental load necessary to understand an operation, assuming its reasonably named. Managing a stack is what computers are good at. Lets optimize our code for how we can better comprehend it--at a consistent level of abstraction with the fewest amount of level changes as possible.
Oh, I wasn't trying to make a claim that this would result in any noticeable performance degradation in the vast majority of cases, but as a means of making code more understandable this particular example suffers in comparison to a comment: less code is on the screen, it requires the reader's eye to jump elsewhere, and again that particular expression is simple and about as easily understood as the function name that replaced it. I think we agree on what to prioritize in writing code, but I don't think that example in the article was a good demonstration of those priorities in practice.
More constructive commenting advice:
If your comments are supposed to explain what the code does, give a few extra minutes to considering whether the code could be clearer (some tasks might require complicated code that merits comments, but most tasks can be accomplished with self-explanatory code).
On the other hand, sometimes there are external reasons, not enscapulated within your code, why you must do something surprising. This unequivocally merits comments. "I did this because of RFC #XYZ" or "Partner FooCorp needs this bizarre format, see /global/path/to/spec", or "our data has such-and-such a distribution, thus this surprising approach, which improves the 99th %ile latency".