I would argue that the need is project-dependent. Personally, I don't write them. However, if there are more than two of us working on Hubski, it's possible that I'll change that approach. Even so, familiarity with the code is what matters most when you are going to change it, and comments could give a false sense of familiarity, or could be misread. I previously programmed in Fortran with a professor that didn't comment. The code was terse, dense, and was expressing models of phase-transitions. Still, comments would have pretty much been a waste of time in that project. When I could read the code, it meant that I could meaningfully contribute. That said, I've never programmed in a large group. I suppose that if I did, I might comment. But, I don't use my phone's calendar because I forget to enter things. Commenting would take some serious discipline for me. I wonder what akkartik thinks of my commit comments. :)
We've had some teething pains, but that's mostly because of moving servers and foisting git on you :) In the abstract I care about commit messages far more than I care about comments, because I believe comments are more useful with a timestamp. But it's still been low down my priorities given all the different technical debt we have to pay off. Since I'm already familiar with arc, comments seem mostly irrelevant right now. They'll become important at some point if we need to involve others. Maybe with the API? :) --- Talking about comments in isolation as a measure of codebase quality is like talking about height in isolation as a measure of mate quality. I think that's what your criticisms boil down to, and they're perfectly valid. If the goal is to get newcomers to a place where they can meaningfully contribute, that drives everything. Well-functioning small teams rely on interactive discussion to orient newcomers. Since it's not clear that comments would ever replace in-person interactions, the default position tends to be that they're unnecessary/luxuries/evil, and that's reasonable. In large teams, in-person interactions gradually get expensive, and that causes greater reliance on comments and other mechanisms. I started out anti-comments, but have reluctantly come around to believing that there's nothing to replace them in certain situations. My current goal is to make the codebase intelligible to others even when I'm not around to explain it. That seems hard enough that I can't afford to be too ideological. Bottomline: comments are sometimes useful, but there's too much dogmatic thinking on both sides battling over them. Attend to the big picture.
It's up in the air. Currently, forwardslash is working on a mobile-friendly version. However, I am seriously reticent to follow an API cycle that has been repeated so many times over the web. That is, an API is released, the site benefits from the creativity and energy of the programming contingent of the community, and then the site moves into a place where the API runs counter to the road map. It's something that we've been discussing.
Personally, at the very least, I think programmers should document their code in some way. This can be anything from a write-up of its overall design if it's going to be left to another programmer, or python / Java docstrings so you can take advantage of the many IDEs/IDLEs that can show you that information on the fly. Comments, at the bare minimum in this case might mean noting places where you are doing something out of the ordinary (Portability provisions, dealing with library quirks, etc) More than that? You'll probably benefit in the long run, but many projects are under time constraints or aren't meant to last.
Any yet they do. There is an awk abomination I wrote for converting IRIS GL programs to OpenGL 1.mumble in the mid-2000s to aid friend in the chemistry department in migrating some software off of Irix on EOL'd SGI boxen. It was supposed to be a one-off. It is still in use, because they didn't want to bother learning a new API. They just added make targets to run the conversion. I don't know, but strongly suspect, that there are poor abused graduate students who would have appreciated a few comments in there.many projects are under time constraints or aren't meant to last.