In most cases I could agree with this. However the big hole in this universal statement, is that it has to assume that a given language is capable of clearly expressing any possible situation. They aren't.
Where it goes even more off the rails is when we are talking about performance optimizations. There is a funny comment war where the RavenDB CTO reviews the code of LightningDB. The RavenDB guy is picking on things like reusing a variable for multiple purposes. The LightningDB guy comes on the thread and says he avoided a stack allocation for perf and you can figure it out if you read the comments. And it goes on like that for a while. Code that is human readable often isn't the best performing at the machine level.
Anyway, I would take it more as a solid guideline for healthy code and less as a hill worth dying on.
assume that a given language is capable of clearly expressing any possible situation
No. I would say there's a completely separate rule for that. One that says you pick a language for a problem, not a language despite the problem. In this case the mistake was the wrong language for the problem, leading to you unable to express the problem, leading to comments needed to compensate so again...comments indicate a mistake made: bad language choice. Which is a huge problem in the industry where people write solutions in languages they are familiar with, rather than what is best for the solution.
I wouldn't die on any hill either. All rules have an exception but like I said before, we NEED to push into the grey area of a rule as much as we can before we accept it.
All languages have to have been created by humans of limited vision and time. There may not exist a language that can clearly express a given situation.
Definitely if your code base has an over-comment/under-expression problem, it’s worth pursuing.
In most cases I could agree with this. However the big hole in this universal statement, is that it has to assume that a given language is capable of clearly expressing any possible situation. They aren't.
Where it goes even more off the rails is when we are talking about performance optimizations. There is a funny comment war where the RavenDB CTO reviews the code of LightningDB. The RavenDB guy is picking on things like reusing a variable for multiple purposes. The LightningDB guy comes on the thread and says he avoided a stack allocation for perf and you can figure it out if you read the comments. And it goes on like that for a while. Code that is human readable often isn't the best performing at the machine level.
Anyway, I would take it more as a solid guideline for healthy code and less as a hill worth dying on.
No. I would say there's a completely separate rule for that. One that says you pick a language for a problem, not a language despite the problem. In this case the mistake was the wrong language for the problem, leading to you unable to express the problem, leading to comments needed to compensate so again...comments indicate a mistake made: bad language choice. Which is a huge problem in the industry where people write solutions in languages they are familiar with, rather than what is best for the solution.
I wouldn't die on any hill either. All rules have an exception but like I said before, we NEED to push into the grey area of a rule as much as we can before we accept it.
All languages have to have been created by humans of limited vision and time. There may not exist a language that can clearly express a given situation.
Definitely if your code base has an over-comment/under-expression problem, it’s worth pursuing.
And that and exceptional exception to the rule in question ;)