"Maybe we just haven’t rethought CLIs since their inception in an environment". And there is a reason for that: backward compatibility. CLIs get used in scripts

"Maybe we just haven’t rethought CLIs since their inception in an environment". And there is a reason for that: backward compatibility. CLIs get used in scripts, and the worst that can happen is to see the script breaking because the command changed. Let's take the example given in the article: it uses sed (created in 1974), cut (created in 1985), and xargs (created before 2001). All these tools are older than Jira and I'm quite sure that using a version of sed from 10 years ago or the latest one with basic flags will give the same result. CLIs are often ancient pieces of software that started as small projects and grew because features were requested while the way it was working shall not be broken as millions of developers use sed in their bash scripts and expect them to work on any kind of Linux machine, old and new. For context, I'm working on a CLI for an enterprise product and we got in trouble just because we were changing error outputs. You just cannot do like on a UI where as long as there is a way to perform the same action as before users will not complain. The second issue is that a CLI is used in two very different contexts: as an application by engineers and as a parts of scripts by those same engineers. This makes it tricky as a CLI developer to know what to do in terms of naming as a daily user will use shortcuts quite fast but a new developer reading a script using our CLI might not understand the purpose of a command. IMO if a CLI has a good documentation (in app and online) you should focus on making your daily users happy as someone seeing the command in a script can check the docs online and hopefully understand what's happening in less than a minute.