New rule for software design discussions: if your argument for a design includes the words "the unix philosophy", your design is automatically rejected, with no appeal available.
If you mean a specific design goal, say what you mean. "The unix philosophy" has half a dozen definitions, unix never followed any of them religiously at all times, and has become shorthand for "I like this and don't feel like unpacking why".
@danderson the Uniux philosophy is that the defaults should be set wrong, and the documentation about the useful options that ought to be the defaults is randomly ordered, goes on at length about irrelevant niche knobs, and has no index.
@dr2chase @danderson Also that the program should implement the same flag-based options as all other programs except it randomly swaps which single-letter flag corresponds to which feature, with a 10% chance of case-change.
@dr2chase @wordshaper Okay so this is a pet peeve of mine, and I'm going to mention it in case someone goes and does something about it. If your program doesn't accept all of '-h', '--help', and if structured with subcommands, 'help', 'help <cmd>' and '<cmd> help', straight to jail.
Double sentence if it only recognizes one, but recognizes some of the others enough to print "I think you meant --help to get help, not -h. Idiot." instead of printing the help, having done 99% of the work.
Nah, "foo --help" should display usage; "foo -h" should respond
foo: halting...
done.
$
Just for fun, because foo's not actually a daemon or anything.
