After the storn, the rains come, and there is new growth.
For each negative point implied, there's a positive rejoinder.
For each positive rejoinder, there is an implied action.
Should Gtk be able to use KDE themes, and KDE to be able to use GTK themes? Should we work on interoperability? If you take away geek motivation, what is left? Money?
I like to dance naked in the rain, to splash my bare feet in the mud of a new spring.
Who will write the call to action that this article seems to demand?
literate programming builds cathedrals
I rather liked the CACM article in which Jon Bentley invited Don Knuth to solve a problem using Web... the result is 16 columns long and uses a previously unpublished data structure.
Jon then invited Doug McIlroy to review the result. Doug gave a 6-line shell script that actually came somewhat closer to solving the original problem.
Literate Programming encourages programming, i think, that's like a mathematical proof: almost completely self-contained.
It's better to redefine a problem so it's easier to solve than to write a complex program.
It's better to reuse than to invent.
Where you need to write a complex self-cpntaind program, literaet programming is surely an excellent approach. Where you need to write a short program that reuses other components and that can be understood and repaired in seconds or minutes, something simpler may be better.
Often, well-chosen variable names are better than pages of (usually out-of-date) comments.
AddToTableOfContents(Name, Page) will almost always win out over attc(buffer, i). A program is called robust if it survives being hacked by people who don't have time or inclination to read much of it.
Requirments documents are excellent, but they should be short, or people won't read them.
The programs easiest to modify are the most honest -- they are written so that you can understand a few lines of code, and then change them, without having to read every function that's called, every method, look at every class.
The needs of small projects are different from the needs of large projects. Most projects are small, and most large projects ought to have been small too. And then you don't need so much documentation.
The manual is the most important. If the manual and the cod disagree, if it's hard to document what the program does, it's almost always best to fix the program.