Having the ability to work with a CLI is hardly what I would consider backwards. It looks great on a resume, especially if you can spin it on your resume with a phrase like “Used (Powershell/Bash) to build a suite of automation tools to send SMS messages when the Database was down”.

When I am responsible for hiring people, a working knowledge of the CLI is something I look for.

It basically comes down to “use the right tool for the job.”

If you have to interact with a user, you’ll want some sort of GUI. We’ve got decades of research and experience showing that they make computing far more intuitive and productive. That’s why GUIs have inexorably taken over the world ever since 1984: they just work better for interacting with people.

But if you’re automating a program with scripts, your program isn’t interacting with people; it’s interacting with a script. And the best interface for that is a text-based one, for reasons that should be intuitively obvious.

The development of CLI programs for users to work with directly is considered backward, and with good reason. But if that’s not what you’re doing, if you’re writing automation productivity tools, then you aren’t doing anything wrong by giving them a CLI.

Eric Raymond’s The Art of Unix Programming is the canonical work for the argument you’re making. I won’t try to condense his excellent book into a couple paragraphs. However, keep in mind that argument applies mostly to programmers, administrators automating tasks using scripting, or power users of highly technical software like CAD.

Even with highly technical users, you have to consider which hats they are wearing at the time. For example, I write embedded software for networking equipment for a living. Our products all have both a CLI and a GUI, but developers almost universally prefer the CLI, due to its flexibility, scriptability, availability, speed, etc.

However, that exact same group of developers overwhelmingly prefers the GUI on our version control software, even though its CLI is more powerful and is supported and documented just as well as the GUI. The difference is we are the end users of the version control software, not administrators or developers.

So carefully consider what roles your users are in when they’re using your utilities, and plan the user interface accordingly. If your boss is mentioning it, chances are you need to improve the documentation and/or training on the CLI at the very least. If you’re constantly telling people a feature is only available on the CLI when they expect it for the GUI, you probably need to rethink your development priorities, taking the needs of your users better into account.

It’s not just Unix that’s driven by command line programs. Microsoft is heading that way too.

Microsoft has been pushing PowerShell for some time now. All of their current server software (Exchange, SharePoint, Server 2012, System Center, etc) can be completely controlled through the PowerShell command line. And PowerShell relies on small functions that do one thing well and pipe data to the next one (though it pipes objects instead of just text).

Most of the GUIs to those programs are simply a frontend to the PowerShell commands, many even tell you what commands it’s going to run to make scripting easier. Everything you can do from the GUI you can do from PowerShell. The reverse is not true – there are quite a few functions that are exposed only in PowerShell.

So if *nix has always done it, and Microsoft is heading that way… doesn’t seem very backwards to me!

I would definitely not say it’s a bad thing. The nice thing about CLI programs is that when implementing them you can have a very restricted scope. For instance, if I want to write a cat clone or “a program to print the contents of a file to the screen”, that’s very feasible with CLI.

However, what if you didn’t use CLI, well then you’d have a basic program with a GUI that displayed some text. But then you’d also have to tie in opening a file dialog and hooking that up.. but then someone also wants to be able to modify the text and save it elsewhere..

Scope creep is ridiculous with GUI apps. It’s so extremely easy to avoid though with CLI apps. “You want to edit the file and then resave it? cat foo > ed > bar” With CLI apps it’s trivial for your users (not you, the developer) to combine it with other tools.

Now, that being said, CLI programs are starting to be viewed as “backwards”. This is because a lot of application development these days happens in marketplaces where users combining your tool with other tools is next to impossible. I won’t go into that here, but I did write a blog post about how “marketplaces enforce master-of-none mentality”, which is the complete opposite of a well designed CLI app (to do one thing and to do it well)

The GUI and CLI both have their place. The GUI is great for allowing a user to perform certain canned operations quickly. The CLI is for when you want to do things the GUI doesn’t allow you to do. The CLI is usually more powerful and harder to use.

A good CLI tool allows the user to do things the person who wrote the tool never thought of. One example is the UNIX ‘find’ command. This command:

find . -type f -name xyzzy* -maxdepth 5 -mtime +3 -exec rm {} ;

finds files under the current directory (but limited to 5 levels down) that have a name starting ‘xyzzy’ and were modified more than 3 days ago and then delete them (note: untested code). And that’s a moderately simple usage. You can use a file manager to do that sort of thing, but it will take longer and is error prone. Of course, being more powerful means the CLI can be more easily misused and create problems for yourself!

A good developer might write a CLI tool in such a way that it also has a GUI allowing a limited set of operations to be performed. The user can start with the GUI and learn the complexities of the CLI later.

A good (long and biased (?)) read on the CLI/GUI tradeoff is at:

http://www.cryptonomicon.com/beginning.html

No, it’s not backwards at all.

The “direction” has a lot to do with our perspective. A user happy with the current path toward simple, “one experience all devices” interfaces is going to see the CLI as a throwback or regression for sure. It’s not in line with their overall expectations.

A programmer, administrator or power user may well see it as the logical progression of tools according to their experience. Many of these start out using GUI tools. When they want to or need to scale, they rapidly figure out why the CLI exists and that progression resonates with those building more CLI tools.

There is this by Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

To me personally, the idea of syntax differentiates the two. When syntax is somewhat present in a GUI, the result is almost never good and as flexible as well thought out CLI syntax. When this is coupled with pipes and redirection, the GUI falls flat due to it not being very useful outside the planned use cases.

My personal preference on this is CLI tools that offer a –gui or –verbose option sufficient to allow a GUI wrapper to interact in a robust way including status bars and other basic elements people look to the GUI for.

Of course the cost of this is essentially two programs with one rather useless without the other, but the major benefit is being able to incorporate one or more great CLI tools into a custom GUI without modification to said CLI tools. Most often this is only done to offer a GUI option on a particular CLI, but the idea of driving multiple tools with one “process” or “use case” oriented GUI can deliver results similar to piping and redirecting and scripting for that use case, making it available to people who would not perform those operations regularly enough to reach mastery while still not inhibiting the CLI users.

I encountered this approach on SGI IRIX and really liked it. I found myself using either the GUI or command line as needed and the nice thing was knowing exactly what the fancy buttons were actually doing.

Where there are lots of different operating environments, the GUI wrappers can differ considerably without impacting the CLI tool as well.

I see this in Linux today with things like disk / filesystem tools, where the GUI can add a lot of value even to CLI familiar users.

In the case of known filesystems / disks / devices, knocking out the CLI isn’t tough, and it can be scripted of course. Mistakes can be painful however.

Where those may not be known, or perhaps performing the operations isn’t done regularly enough to remain solid and error free, running the GUI provides an environment that can be easily verified, operations chained together and then run with confidence, no scripts required.