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.
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 ;)