Nerd Skill Number One
Publication date: 26 April 2010Originally published, in a smaller version, 2009 in Atomic: Maximum Power Computing
Last modified 26-May-2015.
Command-line interfaces, where you just type stuff to the computer and it maybe types stuff back to you, are very important today, and used to be even more important. Actually, they used to be the Universal Symbol of Computer Expertise.
They still often are, in lazier portrayals. The ridiculous user interfaces of computers in movies have moved from unreadable lightning-speed text to preposterous 3D animations, but whatever stupid interface they give the computer-geek character in a movie, if he isn't operating the computer via Tai-Chi holographics, he'll still be typing like crazy.
(Note that if you want to create in your coworkers the impression that you can hack the Gibson with your eyes closed, make sure to get the kind of keyboard that clicks twice for every keystroke.)
Anyone who can recognise a DOS prompt two times out of three may groan when the computer guy on Law & Order has to type really fast to enhance the Web SIM of the kidnapper's IP relay token postcode, but the basic idea that the keyboard is the Interface For Serious Computing is actually not dumb. The command-line's got a lot of life in it yet.
In the olden days of personal computers (well, the relatively olden days), the command-line was the only interface available. If you wanted to do anything more complex than sticking in a disk, tape or cartridge and waiting for software to load, you needed to know the right text commands.
(And you sometimes had to type stuff even then.)
Nowadays, you can do complex server-administration tasks without once seeing a command line. But typed commands still let you do a great deal more. Typing also often gives you a much better way to find things on your computer than a graphical interface can offer.
It's always been a standard geek badge of honour to be able to use command-line interfaces properly. Only Star Trek voice control could really supplant them.
We're creeping closer and closer to that, by the way. Speech recognition always used to be more trouble than it was worth, for able-bodied computer users at least. But computerised dictation now works pretty well. And once a computer can reliably figure out what words the user is saying, it's not a vast jump to parsing "find a photo, from last year I think, of Aunt Nora...".
That's not exactly "Computer! Simulate a Wild West town for me, while I prepare for the safety protocols to as usual fail!", but it'd still be a decent selling point.
We're also just now at the point where, in bulk speech-to-text applications like medical transcription, it's becoming workable to use computers to do a lot of the work. The speech-recognition still needs human babysitting to reduce the number of people who get the wrong leg amputated, but it is finally, for many applications, no longer cheaper to forget about computer recognition entirely and just hire lots of people in India.
(Note that medical transcription is one of the areas where speech recognition can work a lot better than in ordinary dictation. If you're transcribing medical notes, controlling a fighter jet or only telling your computer what programs to open and close, the computer only needs to be able to understand a small fraction of the vast and terrifying total possibility space of natural language. As anybody who's chatted their way through the Windows 7 voice-control tutorial and then been hideously disappointed by what speech recognition then manages to do already knows, "full" language comprehension is a major problem.)
Until someone "solves" natural language processing - possibly creating strong AI in the process - true Star-Trek Do What I Mean computer control will continue to elude us. And the command line will survive.
The command line has hung on for so long partly because nobody's yet figured out a better way to send many sorts of complex instructions to a program. (Or for programs to send complex data to a variety of other programs. Text streams remain a universal interface, and an immensely useful one - UNIX-style shells let you assemble ad-hoc applications out of shell commands on the fly, by scripting or just by piping program output to the input of other programs.)
Various heavy-duty 3D-rendering and scientific-computation programs, for instance, have graphical interfaces for the sorts of things you can do with clicking and dragging, and command-line consoles for the sorts of things that demand eight levels of parentheses. And, in the database world, saying you "know SQL" means you know a command-line interface language, not whatever actual database the language controls.
And, at the other end of the complexity scale, it's just plain hard to make any user interface beyond a basic command-line.
OK, all right, it's actually quite easy to make a graphical interface for even very complex software. This is only true for suitably small values of "graphical interface", though. A single window with 178 controls on it can be made in no time at all. A config dialog that has 47 tabs, including "Miscellaneous", "General", "Misc2", "Other" and "MoreMisc", won't take long either.
If a developer doesn't spend quite a lot of time on getting a graphical interface right, this is the sort of hideous disaster that's likely to result. To avoid it, developers often find they need to make at least some effort to fight the good fight via usability testing; even if you spend months on assembling an interface that looks good to you, it may not work very well for normal users.
In situations like this, it may be a better idea - or, more commonly, it in hindsight would have been a better idea - to forget about a full-featured GUI, and just make the user access some or all of the program's features via good old console commands. (Good freakin' luck getting your friendly neighbourhood PHB to agree to give up on point-and-click for his pet project, of course.)
(To be fair, it actually is possible to make an interface that looks like a total atomic catastrophe, but actually works pretty well. Look at Bulk Rename Utility, for instance. I suspect BRU's author spent only slightly longer on the interface than he did on the program's name, but once you stop laughing at the explosion-in-a-widget-factory presentation, it's actually quite usable.)
A command-line interface, in contrast, can require pretty much no development time at all. And it may scare off casual users and be a pain for everybody else until they learn the options and switches - but at least, then, it'll work. An awful GUI is awful for everyone, forever.
Many kinds of software are fundamentally incompatible with command-line control. People wouldn't queue up to buy command-line Grand Theft Auto, and I presume that one of the things people have to do in hell is draw perfect reproductions of Old Masters using a command-line version of Photoshop. But a lot of very complex, modern software still talks in simple words and numbers. Knowing how to speak that language properly remains an immensely useful skill, provided you keep up with recent dialects.
The obvious example of a ubiquitous modern command-line interface is Google. It's got a decent suite of basic logical operators, numeric-range values and unit conversions, and an ever-growing collection of other oddities, like package tracking. Many Google users don't even know about putting phrases in quotes, but a small amount of help-page research (or just adding the word "please"!) can really pay off.
(EBay has logical operators
too, by the way, which are
faster to use than the full "advanced search" page.
Note that it'sfoo OR bar
on Google, but(foo,bar)
on eBay.)
A lot of old command-line software, especially on un-networked home computers, had great program-control complexity but worked on very restricted data sets. Google is the other way around; there aren't that many special options, but the data-set is gigantic. This leads to interesting new tricks that previously only interested professional database wranglers.
Like, suppose you're looking up some fairly obscure subject, and the "best" page Google finds for you is a small, badly-written Wikipedia article with no references. The PageRank-zero personal site with the answer to your question is out there somewhere, but it'll be pushed well off the first results page by umpteen copies of that Wikipedia article on podunk ad-farm "encyclopedia" sites that take advantage of - or completely ignore - Wikipedia's generous licensing terms.
To avoid seeing all those, you need only add -"[some string from the Wikipedia article]" to your Google search. Usually, it only takes one such minused phrase to clear sufficient of the copies that the page you really want will bubble up onto the first page of results.
This is connected to an interesting, and immensely useful, property of human language, which is that the combinatorial explosion of possible grammatical sentences (as opposed to random strings of words, or of letters) means that most sentences of only six words are likely to be unique.
Try this yourself. Take some six-word sentence, or even a six-word piece of another sentence, which you've spoken or written today, and plug it into Google as a quoted phrase search. If your phrase wasn't a quotation, cliché, error message, standard part of many Web pages or concise reference to some very common concept, there's a good chance that it doesn't exist anywhere in Google's frajillion-Web-page database.
I just tried this with "needs to have about six words"; zero hits, though that will of course change when Google indexes this page. "Doesn't exist anywhere on the Web" exists in many places on the Web, though! See also the xkcd IRC channel where you can only say something that nobody else has previously said.
The remarkable specificity of surprisingly short strings explains why another modern incarnation of the command-line, whole-system search, works. You usually only have to feed a few characters to Apple's "Spotlight" or Microsoft's "Copy Of Spotlight" for them to give you a very short list containing the program or folder you're after.
(If you'd prefer a simple whole-system filename search that gives instant results, and you're using a remotely modern version of Windows, try Voidtools' "Everything".)
Search-string creation is a fundamental part of modern text-interface computing, and learning a little about it can help with searching within documents as well as with Internet searches.
Take, for instance, the fact that a string is made of characters, not words; as far as the computer's concerned, "space" is just another character, and if you treat it as such, you can find things faster.
Example. If you're looking at the 15,000-word Wikipedia article about Jimi Hendrix and want to find the bit where it talks about "Little Wing", what every newbie does is start typing L-I-T-T-L... into the search box. That'll get you there, but only once you've typed "little w". The first seven keystrokes will find you "Little Richard", "little trouble", "little regard"...
The faster way to find what you're after, for a multi-word search, is to type a few letters from the end of the first word in the string, and the space, and then start typing the second word. Do it this way and "le win" or "e wing" will find what you're after.
In this example you only save a couple of keystrokes. But, one, every little bit helps. And, two, this was just the first example I chose after hunting for musicians with big... Wikipedia articles.
Browsers like Firefox that have "search as you type" make it easier to learn good habits like this, because you can see exactly how many characters you have to type to find what you're looking for, rather than pressing Enter to see if you've got it right yet. Google's Chrome browser deserves a special mention - it's not only got search-as-you-type, but also highlighting of every matching string in the page, and it puts little yellow highlight lines in the vertical scroll bar to show you the location of every match for your string in the whole page, not just the portion of the page that fits in the window.
Command-line computing is more than fifty years old now. People were doing this stuff via teletype, before monitors existed, and when you still counted yourself lucky if you didn't have to provide all of your input as punched cards.
The command-line has changed a lot less than computers have over the intervening years, but it has still diversified immensely. Notably, there are now lots of "simplified" command-line systems, like Google and eBay, which don't let you create super-complex expressions, but are easy to learn. (See also, shells that know what you mean if you type "rename *.htm *.html".)
You used to always have to type exactly the right thing, leaving the computer no room at all to interpret your input in more than one way. And you still do, if you're using some precisely prescriptive command-line interface like the everyday DOS prompt, raw SQL queries or regular expressions. But nowadays, near enough can be good enough, in what you tell a computer you want, in how it guesses what you mean, and in what it then gives you.
The basic skills of the keyboard jockey, though, remain useful today. There's little reason to know how to work an adding machine today, and there's also limited demand for people who can operate punched-card unit record equipment. All those zillions of person-hours spent learning WordStar commands are also, today, lost like tears in rain.
But if you're there when a time-travelling computer expert arrives from 1957, just point him to YubNub.
He'll feel right at home.
