Sorry if I'm feeding the troll, but... On 29 March 2010 00:05, Eris Discordia <eris.discor...@gmail.com> wrote: > 1. ... not comment their code?
Comments lie. Code can't. Hence clarity of code is better than commented theses. > 2. ... not include usage instructions? $ man cat > 4. ... not include a preamble introducing their file, automatically assuming > they work in "clean environs" where nobody except people they know on a > face-to-face basis commits to their code repository? It can be identified by its filename. > 5. ... not accommodate their user base insisting they know better what's > good for the users thereby dramatically cutting down the number of people > who may want to merely use, and not hack, their code? Every user wants something different and incompatible. One cannot accomodate them all. > 6. ... forget to see past appearances in others' code instead of simply and > rationally counting the lines of code in the body of function 'simple_cat' > for a proper comparison of equivalent functionality between a feature-heavy > 'cat' and a minimalist 'cat' each with its own merits? A feature-heavy 'cat' has no merits beyond the minimalist 'cat'. If you want more features, write a new program. See: cat -v considered harmful. > 7. ... avoid provisioning for a time when 'coreutils,' in order to become > feature-heavy, will inevitably contain copious amount of code that needs to > be amenable to automated testing and documentation? See above. A program becoming feature-heavy is a failure in and of itself. Less is more. > 8. ... avoid any secondary optimization of their first solution under the > illusion that every optimization counts as the dreaded "premature > optimization?" Simplicity is more important than efficiency. Optimisation should only be done when there is an identifiable bottleneck. Cat has no such bottleneck that I'm aware of. > 9. ... condescendingly refuse to write or maintain code that is capable of > cooperation with a dominant archaic design which can only be phased out > gradually? Why does it have to be phased out gradually? The problems of Unix are too deep to fix. > 10. ... allow themselves to be flattered by agreement from the close-knit > community of like-minded developers fully shutting their minds close to the > potential merits of functionally rival software? If it's better for the system's users, it's better for the system's users. Again, sorry. cls
