As I was thinking about this some more, checked exceptions start looking like explicit typing. The reason people want checked exceptions is to make sure that no error conditions go unprocessed. Same thing that explicit typing people want. But let's apply the testing argument. If your testcases actually tested the relevant error conditions, then you wouldn't need to have a language mechanism to ensure that the errors got handled. At least, you could make all exceptions unchecked, and eliminate the multi-arm catch hairballs that are lying around. It's not like all those catch blocks that are empty, printing stacktraces, or logging exceptions are really improving the robustness of the systems that they are in.

He concludes with a section about comments intended for comment processors like doctest, iContract, and XDoclet.

All of these functions of comments as metadata could be implemented by extending the language instead. (Contracts are from Eiffel, for example, which supports them in its core syntax.) However, the use of structured comments as metadata lets a third-party tool address a gap in the language in a way that leaves the source structure intact for compilers and other source processors (such as editors, source debuggers, and refactoring tools) that wouldn't recognize an extended grammar. Just as comments are an escape hatch for human readers, they're an escape hatch for development tools as well.

And these two kinds of comments - natural language and structured metadata - are related. They both add information that can't be expressed in the primary programming language. And they're both useful to humans too.

Marc is asking about standards. As far as I know, we don't really have much experience with this kind of metadata in real world, real scale applications. Seems early for standardization. Of course, that never stopped the W3C or the JCP.