From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <989B4954D6C952C13793229D@192.168.1.2> References: <14ec7b181003251133u3aac09f1qcee452382386ec19@mail.gmail.com> <8ccc8ba41003251417x1ec6a645y171736b0fbe6a352@mail.gmail.com> <989B4954D6C952C13793229D@192.168.1.2> Date: Mon, 29 Mar 2010 00:41:07 +0100 Message-ID: From: Connor Lane Smith To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] quote o' the day Topicbox-Message-UUID: f74fbfa2-ead5-11e9-9d60-3106f5b1d025 Sorry if I'm feeding the troll, but... On 29 March 2010 00:05, Eris Discordia 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