5 ms·
What I'm saying is that flag feels like a "worse getopt," and you seem to be going from the assumption that if you need more than 2 flags you should roll your o
by lukeschlather 12y ago
What I'm saying is that flag feels like a "worse getopt," and you seem to be going from the assumption that if you need more than 2 flags you should roll your own DSL parser, which sounds to me overengineered and harder for others to pick up. Most programs are not tcpdump.
- tptacek 12y agoI guess my argument is: It's OK for the standard library to satisfice or even constrain flag parsing, because programs that need "complicated flag parsing" are better served by something more sophisticated than flags anyways. Super-awesome flag libraries just trick programmers into building bad UX. A lot of programs would also be better off if they reduced the numbers of flags they had, and made the "value" of those flags more sophisticated. In other words: taking some of the weight off the flag parser. Most programs aren't tcpdump. Most programs don't have a lot of flags. But most programs that do have a lot of flags would probably be better off with something other than flags as their command line idiom. "tar" springs to mind. It's hard for me to look at my zshrc and see all the aliases with their -fNqC's and -avz's and think "this is a good command line user experience". Many of these flaggy CLI programs have terrible UX. There's maybe a "Gettysburg Address In Powerpoint"-style satire to be done of, say, awk commands expressed entirely in flags.