parallel structures are necessary

[doom]

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.

BrowserUk wrote:

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.)

[BrowserUk]

In general, I'm afraid that this piece stikes me as an extended rationalization for being lazy about documentation and writing uncommented code...

Sorry, but that first sentence indicates that you have not read what I wrote, but rather skimmed a few bits and reached a conclusion based upon what you think I probably wrote. Eg.

Comments are not, and should not be, documentation

Documentation of code is vitally important for successful, ongoing projects, but comments are not documentation.

I have no problem with you holding a different opinion to myself, but don't put words in my mouth, or draw concusions based upon things I haven't said, much less things I specifically and deliberately already countered.

Eg.2

I (BrowserUk) wrote the article, but you've addressed your reply, and attributed my words to graff. If your comments and documentation are as good, you are welcome to them :)

[doom]

In general, I'm afraid that this piece stikes me as an extended rationalization for being lazy about documentation and writing uncommented code...

Sorry, but that first sentence indicates that you have not read what I wrote, but rather skimmed a few bits and reached a conclusion based upon what you think I probably wrote.

I'll plead guilty to trying to intuit what's going on in your head, based on this long and rather strange essay that keeps harping on how words are slippery and difficult and have little place in the pure, pristine world of code.

To go even further, I think you're someone on a quest for absolute certainty and perfect mathematical order, and I suggest that this has little to do with the world of programming, which is a collaborative effort among human beings.

Documentation of code is vitally important for successful, ongoing projects,

Correct me if I'm wrong, but isn't this the first place where you've said this? (( Actually, I am wrong: it's a line from the original essay. ))

I have no problem with you holding a different opinion to myself,

So you're not the guy who keeps initially down-voting everything I say in this thread?

I (BrowserUk) wrote the article, but you've addressed your reply, and attributed my words to graff.

Fixed. My apologies. There's a reason for the threading glitch (I deleted some material commenting on graffs remarks), but it's not worth going into.

If your comments and documentation are as good, you are welcome to them :)

Well you know, "Love the truth but pardon error."

[Anonymous Monk]

Comments and docs are issues. But with automated tests, you have to treat them as the running specs of the system. If you change the specs, then you have to change the test cases, and only then, can you change the code to conform to the tests again. In fact, you should never be able to successfully compile your entire project if a test fails. That way the test serve its purpose and it never becomes out of sync.