Well, native language and programming languages aren't the same thing and you express yourself differently in them. That's basically a given.
But comments are most useful when they explain why something is being done, not what's being done. The latter is usually simple to work out with even the most hideous code. But if I don't know what you were trying to do or why you did something in a particular way, seeing what you did alone may not be all that helpful, especially when maintaining code.
native language and programming languages aren't the same thing and you express yourself differently in them
Indeed. However, when developing software I'd expect that the responsibility is first to express yourself clearly in code and only second to express yourself in prose, which means if you're taking very much time to do the latter it's time that could be spent doing the former.
Yes. The industry is full of hacks. I don't see how that's a problem with comments though. They're going to write hideous code with or without comments.
The problem is that comments visually bloat the code and make it harder to understand. Bad code with useless comments is worse than bad code with no comments. And that's not even counting comments that are out of date and misleading...
And bad code with good comments is more useful than bad code with no comments. It strikes me that replacing "comments" with "tests" in much of our thread would lead to the same outcome. I guess we're just going in circles on this one.
> The problem is that comments visually bloat the code and make it harder to understand.
That's a good reason to avoid breaking up logical blocks of code with comments.
Its not a good reason not to comment.
> Bad code with useless comments is worse than bad code with no comments.
That's a good reason to have code review (which includes review of comments) to ensure that there is neither bad code nor useless (including out of date or misleading) comments.
But comments are most useful when they explain why something is being done, not what's being done. The latter is usually simple to work out with even the most hideous code. But if I don't know what you were trying to do or why you did something in a particular way, seeing what you did alone may not be all that helpful, especially when maintaining code.