> Even more than that though, describing what something is is usually not sufficient. You also have to describe why it's useful, or rather what it's for. The t

> Even more than that though, describing what something is is usually not sufficient. You also have to describe why it's useful, or rather what it's for. The thing is, these things are very abstract. The signature is what they are and why they are useful. A way to think about them is that they were discovered. People wrote a lot of code, saw the same pattern come up over and over again, and named it so they can abstract over it and reason about it. > This is analogous with comments in code - in well written code you don't need many comments telling you what the code is doing, it's often fairly clear. They're also for convenience not necessity because you can, with enough time, figure out what the code is doing because you have all the information. What are irreplaceable are "why" comments telling you why something is done. E.g. "this prints two newline characters at the end of the document" is inferrable, but "print two newline characters because X program is unreliable unless we end with a blank line" is invaluable. I agree with you here. The problem is that it's very hard to describe why they are useful if you didn't encounter the problem they solve yourself.