> When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it.
I think what's interesting is that, in the space of programming language development, languages that tend to have a more consistent feel across the language (such as Clojure, Python to some extent) tend to have BDFLs and came from a single person.
I know this sounds boring, but I enjoy looking at how programs manage command-line options. There are so many libraries in many languages. Some require structures so that help screens can be autogenerated. Some allow grouping of options `tar xvzf`, some don't require a dash, some have one-dash for short and two dashes for long options. Some require `=` between parameter and value, some (like mbed, npm, yarn and git) have subcommands and sub-subcommands.
It is truly fascinating the number of ways command-line parameters have been handled over the last 40 years.
I think someone on HN should write a blog post covering the history of CLI options. Wait, I bet there are 50 if I googled...
Python an interesting example because, as the BDFL has ceded more control over development to others, it has been gradually losing some of that consistency.
I think what's interesting is that, in the space of programming language development, languages that tend to have a more consistent feel across the language (such as Clojure, Python to some extent) tend to have BDFLs and came from a single person.