Don't write command-line interfaces (and how to write if you have to)

Don't write command-line interfaces (and how to write if you have to)
arogozhnikov.github.io

Any system worth keeping around should be a library (or family of libraries) which have a CLI fronting it that serves to pass parameters to it just as you might any other way (such as through some other program or REST API or GUI). Agree the CLI "shell" around the system should not have separate logic, but should report back logic faults from within the library.

When I started these were a norm and I learned to be proficient well before I started to use graphical applications.

While I can easily move around any graphical application I do circles around other developers I work with when it comes to tasks like operating on files, moving them between servers, etc. even when those people use their best tools they know and have been using for a long time.

Coupled with ability to type fast (yes, I had touch typing on an electric typewriter at school), command line interfaces tend to scale much better with complexity of the operation. Change to a subfolder and maybe a mouse-driven app is going to be faster. Change five levels down, then three levels up, then repeat five times with small variations doing some operations, and mouse user has no chance to keep up.

Also there is only so many things you can click on (ie the surface of the screen) so you have to click on things to uncover other options to click on, and so on. All this is slow because typing is much faster than pointing and clicking. I type 5 to 10 characters per second, easily, and that I think is not possible for a mouse-driven application and touch interfaces are even worse.

Commands basically open an infinite amount of possibilities with very few keystrokes as long as you have experience composing them. On my machine I press ctrl+n and start typing name of the file and I am instantly brought to that file. With a mouse I would first have to navigate to some kind of commander or explorer-like application, start going through folders (assuming I remember where the file is) or maybe click on some kind of search and then browse through results. That takes time and I am usually under a two seconds to reach most files on my system.

My theory is that people who started learning with newer technology that does not afford so much in terms of composability never learned to solve a problem this way. Also the new technology tends to change a lot faster than in the past, making it obsolete sooner which causes people to overlook advantages of learning their tools really well.

Core functionality should be in functions, classes, etc. and a CLI utility can be separately written or synthesized that imports that library, and anything wanting to implement a different interface can do the same.

Isn't that the way it's normally done? Real world example is libcurl and curl command.

All of the time I'm spending with these settings, I'm thinking to myself: Just give me an RS232 port, so I can plug in a dumb terminal and set everything up using a CLI.

But not all is lost. I've noticed that more and more web pages that give instructions on setting up computer hardware and software start with: "Press Windows-R and type CMD, now enter the following commands." And I don't search for programs any more. I press the Windows button and enter the program name from the keyboard.