Re: [9fans] quote o' the day

[Connor Lane Smith <cls@lubutu.com>]

Sorry if I'm feeding the troll, but...

On 29 March 2010 00:05, Eris Discordia <eris.discordia@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