Modern CLIs Evolve with Object Command Model and API Integration

Key Quotes

"A command line interface is an interface into a computing environment right that is predicated on a terminal and generally a shell and you know the terminal gives access to the computer the shell enables both scripts and programs and these programs or these clis are literally built to do discrete pieces of work inside of an operating system whether it be at the operating system level or with a business application."

Derick Schaefer explains that a CLI is fundamentally a gateway into a computing environment, accessed via a terminal and shell. This interface allows users to execute discrete tasks within an operating system or application, distinguishing it from the underlying commands themselves.

"So historically we went from punch cards as the interface to invoke functionality and commands to a terminal which was a gateway into a shell that enabled access to scripting environments and commands and then obviously in the modern world we use graphical gateways such as applications and browser based apps and mobile apps."

Schaefer traces the evolution of user interfaces, starting from punch cards to terminals and shells, and finally to modern graphical applications. This historical perspective highlights how the CLI, through the terminal and shell, served as a crucial intermediary for interacting with computing systems before the widespread adoption of GUIs.

"So first of all if you think about scale the original cil mantra was within side of an operating system and it might venture its way something such as r sync to where it's going to communicate between another machine but when you look at git we are talking about local and remote connectivity and the ability to manage both sides of the repository equation at scale across hundreds of millions of users it really thought this out in a way that though people will run into their challenges with their repo you don't see the challenges of repository management of the past to where code is lost and documents are you know overwritten you know they really got that right at scale and i think that that was a very modern forethought on behalf of the designers and and the maintainers today is to make this work at scale."

Derick Schaefer highlights Git's innovation in handling scale and remote connectivity, a significant advancement over earlier CLIs. He points out that Git's design effectively manages repositories across millions of users, preventing common issues like lost code or overwritten documents, which demonstrates a modern approach to large-scale distributed systems.

"So the modern command line interface finds itself more organized around making these remote calls versus calling an operating system function or versus calling a function from a local package that might be compiled into it though that's still fair game for the function of a cli we see a lot more remote communication with apis and kind of a more modern sense and to be honest any cli designer really needs to think about leveraging once again the unix philosophy do something well and play well with others and part of that play well with others has extended from standard in standard out to being able to make an api call out and receive data back in as a part of that work stream if that makes sense."

Schaefer explains that modern CLIs are increasingly focused on making remote API calls rather than just local system functions. He emphasizes that this shift aligns with the Unix philosophy of doing one thing well and playing well with others, extending this principle to include network communication and data exchange with APIs.

"So first of all you want to shorten it as much as possible in a responsible manner and then to the extent that it's going to have to continue to be longer or run over periods of time that might be subject to interruptions or failures you're going to want to go back to tried and true design tactics such as is having breakpoints recovery points being able to do retries and not lose that work that has been in process."

Derick Schaefer advises that for long-running tasks in CLIs, the primary goal is to shorten their duration responsibly. He stresses the importance of incorporating robust design tactics like breakpoints, recovery points, and retries to ensure that work in progress is not lost, even if interruptions or failures occur.

"So first of all huge fan of json and i do think that any modern cli should have json as an output option not as the default but as an output option I'm going to throw a twist into the conversation that in the unix or linux world the expectation has always been exiting an exit code and that your data is going to be in the you know standard out or standard error pipes in the powershell world that changes powershell returns an object a json object and though it sets an exit code an administrator has to go look for that so if you write a cli today that does not support json you are immediately handicapping yourself in terms of your interoperability in the powershell world."

Schaefer strongly advocates for JSON as an output option in modern CLIs, though not necessarily as the default. He explains that while traditional Unix/Linux CLIs rely on exit codes and standard output/error, PowerShell's object-based return, including JSON, necessitates JSON support for effective interoperability in that environment.