|laziness, impatience, and hubris|
parallel structures are necessaryby doom (Deacon)
|on May 09, 2007 at 03:37 UTC||Need Help??|
In general, I'm afraid that this piece stikes me as an extended rationalization for being lazy about documentation and writing uncommented code... my personal experience is that if the programmer is under the delusion that the code is "self-documenting" you might as well throw it away and re-write it than attempt to figure out what's going on with it.
One of the strengths of the perl programming culture is that so many of it's programmers are also fluent in English, and have no problem with writing comments, pod, web pages, articles, books, etc... One of my slogans these days is that "perl is the best documented language in history". If this approach bothers you, maybe you should be looking into a language with a culture that's more suspicious of words.
One of the high priority goals in programming is the removal/avoidance of codependencies. We avoid using parallel data structures (eg.parallel arrays), because it becomes a nightmare to maintain those parallel arrays in synchronisation as algorithms and projects evolve. One of the key attributes of well designed classes (and other abstractions), is that they are as fully independent of their peers as possible. As decoupled as is possible to achieve.
This is a clever line of argument, but I don't think it applies to the subject at hand. Nearly every workable methodology for verifying the correctness of code involves comparisons between multiple implementations of the logic: the code isn't complete without documentation (and specs?), and these days most of us would say that it isn't complete without automated tests.
Note that automated tests have the same problems you're complaining about with comments and documentation: when you make changes it's likely you're going to need to make changes in all of these roughly-parallel structures: code, comments, docs and tests.
(Update: Fixed attribution of quote to BrowserUk.)