Terminal Interface
I twhined this morning about having to use a terminal emulator. Terminal fans let me know that they love their terminals and will only give them up when someone pries their cold, dead pinky off the control key. My attempts to explain myself via Twitter only made the misunderstanding worse, so I waited to explain myself here in more detail.
Part of my reaction to having to use a terminal (I was operating Git) came from having to use one on a Mac. I lived on Windows machines for 15 years and having to drop into a terminal somehow didn’t seem like that much of a step down. On the Mac, though, user interfaces are generally enough more polished that the contrast is starker.
Another part of my reaction was a flashback of sorts. I grew up in Silicon Valley in the 60s and 70s. It was a time of excitement and promise. Computers were going to change the world. Yes, what we had was primitive and required extensive cognition and human memory to use, but that was temporary. All that would change once we had enough CPU and RAM.
Here it is 2010 (almost). I have four or five orders of magnitude more processing power now than I had then. The best way for me to interact with all that power is a paradigm that was invented 50 years ago for a completely different set of technical constraints? Really? I suppose I’m more disappointed than anything else.
I’m not trying to diss terminals. There is a lot to be said for terminals. They are efficient in pixels, in keystrokes, in bandwidth, in computing power. They are flexible and familiar. In expert hands they can be extremely effective.
For example, I found Gary Bernhardt’s excellent video of refactoring Python both inspiring and frustrating. He works in a terminal-based editor, and he is clearly a virtuoso operator. He is efficient and accurate with his keystrokes. The inspiration came from watching his responsive style, working in small, safe steps. The frustration came during the long stretches of text editing operations. “That’s an ‘extract to component’,” I wanted to say to the screen as he hammered away expertly on his keyboard. I could see that if he had an interface with more structure than text he could accomplish his task in less time and with fewer mistakes. He could stay focused on the design of the software he was manipulating. Most importantly, a structured interface (say, one with an “extract to component” menu item) is accessible to all the people who don’t take the time to master their text editor. It seems a pity to waste precious neurons carefully planning editing operations when there are programs to design.
The disadvantage I feel most keenly when using a terminal is the cognitive load. I have to keep more in my head when using a terminal/command-line-based interface. I need to remember the context for my decisions in between operations. Any translation from verbal/symbolic thinking to (for example) visual thinking I have to do myself. All that computer power that was supposed to liberate me from such drudge work is sitting their idle while I struggle to remember.
Twenty years ago I had IQ and memory to burn. At 48 I learn more slowly and remember less clearly, so the demands of a command line are more significant, especially if I don’t use the software all the time. I don’t want to go all Flowers for Algernon on you here, at least not now, but I notice that I spend less time solving my problem and more time remembering the operation of the interface when I’m using a terminal.
What it comes down to for me is a question of responsibility. What are we as programmers responsible for? Implementing useful functionality? Presenting that functionality to users in a way that lightens their burden? Back in the old days we were clear that we were responsible for both (some of us, anyway). Then we discovered that interfaces that engage more of the brain than the verbal/symbolic parts are hard to write, harder than implementing useful functionality.
There seems to be a movement afoot to stop at implementing useful functionality and let the user’s experience of it be their problem. I see this as false economy. A million users using their own memory and cognition to operate an interface is wasteful if by reasonable extra effort the programmers could enable the users to stay focused on their tasks instead of the interface. However, as long as there are people willing to use terminals, programmers are tempted to stop once the functionality is working and go onto the next interesting problem, leading to an understandable tragedy of the user interface commons.
Computers could have been more than glorified terminals. They still can. But it won’t be easy.
Re using Git: have you tried TortoiseGit? http://code.google.com/p/tortoisegit/
dear luke, does TortoiseGit run on a Mac?
A few possible explanations could be offered :
a) The programmer (or author) for a variety of reasons was not willing to expend any more time and energy than minimally required. For the programmer, it is economical to offer command line interface due to any combination of lines of code, languages known, platforms to be supported etc. Or the programmer may himself be comfortable with command line, is really writing the program for himself and also happens to be distributing it since it isn’t unhelpful to do so. In a sense the programmer is optimising for himself, not for the users. For free software, command line free software definitely is better than no software. I do wonder how many commercial softwares today are shipped with command line interfaces.
b) The programmer may choose to use command line as the least common denominator to support a variety of possible interfaces each being authored by someone else. The intent here would be to focus on the core processing engine, and invite others to build the attractive interfaces on top of it. Thus an eclipse plugin for git using a command line git interface is more likely to be useful to end users of eclipse and git than a separate client (even if it is integrated into the OS file browser).
I submit both the scenarios above (and perhaps many others) are valid use cases for continuing to build command line interfaces.
Correction above :
I meant an eclipse plugin for git which internally uses a command line interface to git.
I have been using Macs since 85, and I can count the number of times I’ve really needed to use a terminal on one. To this day, I use a terminal to interact with a headless server out in the ether somewhere (via ssh,) and for nothing else. That said, there are folks who love OS X for its BSD heritage and spend all day in the terminal.
My advice is to stick in there and try to learn the way to do things in the Mac GUI. Also, try Quicksilver which gives you a lot of the power of the terminal (e.g. for launching apps, finding things in files, manipulating large batches of files, etc.)
Also, for git on OS X try http://gitx.frim.nl/ Tortoise is for Windows.
Dhananjay,
I agree that programmers make user interface decisions based on the criteria you list. We do for JUnit, for example. We write an engine with a programmatic interface and expect other people to write pretty GUIs (although mostly they haven’t so far). The fact that these are common criteria, and commonly accepted criteria, is a sign that computing has dramatically lowered its expectations. It’s a shame when we are willing to limit our aspirations to serving people who are primarily verbal/symbolic. Serving people who think differently requires empathy and significantly more programming, but whether that investment is worth it depends on the scope of what we’re trying to achieve.
Diss has 2 ss’.
http://en.wiktionary.org/wiki/diss#Verb
I completely agree with your complaints, Kent, although I suspect that our ideal solutions might differ somewhat. I love the conceptual model of the Unix command line, but I dislike the arcane, arbitrary details and wish for a richer, more graphical terminal experience. I’m enamored with the conceptual model of Vim as an editor, but I constantly wish that it could view text at higher levels of abstraction than simply “a series of bytes.”
I’ve been testing the waters of automated refactorings with Vim and Python, writing a few of them in pure Vim script. There are also some existing tools out there already, and I use one to do some automated Extract Methods in that screencast, but there’s nothing that even approaches the refactoring power of a modern Java IDE. Unfortunately, because Python is so dynamic, I doubt that we’ll ever see the levels of automation that Java achieves – even finding uses of a Python class is an undecidable operation. The one consolation I can take is that Python’s terseness leaves less code to refactor.
IDEs, with auto completion, syntax highlighting, refactoring tools, an dozens of other features are great.
But, a good set of command line tools and a scripting language allows for automation and customization that no IDE or GUI would ever be able to handle. Generating a test data file on the command line or with a quick script is essential. Being able to quickly find all references to a particular class, even in configuration files is trivial with find, xargs, and grep. However IDEs typically will only search source files, not configuration files. Automation of build, shutdown, redeploy, and startup is as simple as a couple && between commands (and an up arrow to re-execute).
Thanks. Fixed.
While dynamic languages to create some challenges, I’ve used the Smalltalk refactoring browser for 15 years and it works very well in practice. Often with refactorings you can’t implement the general case but you can implement enough common special cases to make the refactoring useful in practice.
A thoughtful article, I especially sympathize with the comment: “I suppose I’m more disappointed than anything else.” Me too, but I can’t think of something better.
If you were to imagine an interface to git, for example, that transgresses the terminal interface, what would it look like?
Git, in particular seems like it could stand a better tool to interact with it. I can’t imagine that tortoise, for example, is very fulfilling to this end though. One complaint you issue about using the command line is that you have to *remember* a sequence of actions, in this case: check status, add files to index, commit files. This is a workflow that you still have to memorize in a gui interface and it doesn’t necessarily mean that its easier to understand the workflow with a menu driven contextual menu, or batch of icons, aka tortoise.
Nothing can replace the terminal in my opinion. Illiterate users that are glued to their GUI interfaces are in an uncomfortable setting because the ‘options’ are not tangibly visible; whereas, they are (to a degree) in a GUI. Use of the command line requires learning many fundamental tools that are enormously useful, as stated by Aaron Day.
The terminal, though, does not properly replace the many functional uses of a solid GUI; a GUI is also more attractive to use
The lovely thing about Mac OS X, is, the beautiful Aqua GUI interface in addition to the Unix command line, utilities, and shells! It is a beautiful marriage of eye candy and old school tools. (No, I’m not a fanboy, but I do I love Apple’s product)
I highly suggest you get your hands wet a bit more, install Cygwin on your machine and start automating your repetitive and common tasks on Windows with *nix utilities (grep, sed, awk, bash, etc…). It will give you a broader view of using computers than the one Windows has shackled you into.
Hooray for productivity boosting GUI-based tooling. Equally, hooray for TextRunner and the shell that runs it headless on some server at 3AM while I sleep. GUI for productivity in creation; CLI for productivity via automation.
The best GUIs (or the best features in them) encapsulate workflows into smaller ones. While you may know or memorize the underlying steps, you don’t have to follow them *every time* (cognitive load, as Kent put it). My favorite example is the CVS integration in eclipse which never forces me to update. Edit, commit, done (in most cases). Via CLI, there’s *always* the prerequisite `update` step.
Ah, I was waiting for this article since I read the teaser on twitter!
I’m with you in one way: As a kid, I loved computers, because computer means magic, means a dream become solid reality, means make your own Star Wars epic movie in five minutes. I was very disappointed as I found out that most stuff with computers had nothing to do with Star Wars. But it came to me later, as in The Matrix (just to stick with movies): At some point, you stop seeing text and start seeing your vision. All in your head.
It’s plain to see that all the nifty visual stuff on computers is meant for “business users”. This is the easy part, because you figure out why somebody buys a computer, then you cut away anything he don’t need and anything which might confuse him. (Actually, this is hard enough.)
People customizing a computer (as developers and system administrators do) potentially need access to any functionality the machine might provide. Therefor, you cannot safely cut away substantional parts of functionality. The Terminal provides a cheap, relieable, low-complexity, universal interface to everything. Terminal survived for decades, constantly evolving very, very slowly, because there is simply no better idea around yet.
So whatever once might replace Terminal will need to be another kind of Terminal.
I think this discussion is worth a more deep exploration. It’s not the first time that someone is unsatisfied with the current UI paradigms and tried to conceive (and sometimes work on) a new solution, but as far as I can see, no one has reached the masses.
Sadly it’s not sufficient to complain (even if it’s still a necessary step): ok, maybe there is a problem. Where is a possible (viable) solution? There is someone working on it? I don’t know. But if it’s important, then we have to speak more “loudly” and reach a wider audience to have a productive discussion.
KDE4 and e17 for example are trying to innovate, but we’re not there yet.
We need:
– A problem: clearly stated and argumented (rationally and pragmatically)
– A discussion: a creative one, to propose and reach a consensus on a solution
– Marketing: to gain momentum and attention from the general public (of programmers and beyond)
– Some WORK: for making the solution something REAL. A startup? An OSS project? The sky is the limit.
Again: if it’s important (even if a long term importance), it’s still worth to discuss it and to try to do something about it. Talking is necessary but not sufficient to do a real difference.
PS: Sorry if I sound too preachy, this is my humble opinion. And for now I’m not sufficiently qualified and experieced to try to propose something that is: efficient, usable, fast, flexible and a pleasure to use at the same time.
ADDENDUM
————–
An interesting practical experiment on a new UI is Sugar:
http://wiki.laptop.org/go/Sugar
I think it’s worth a look (I’ll try it in a near future).
Kent,
I completely agree with you. Despite the reliance of others in my field, locally, who swear by such rudimentary tools, I tend to prefer Eclipse as my “editor of choice” for code authoring. I, too, long for a better interface for my server than terminal emulation affords, and I’m constantly looking up some relatively simple but infrequently used function or command because I can’t afford the brain space to memorize it. Thanks for writing this.
Has everyone forgotten automator? Out of the box Snow Leopard does not have access to every feature of the command line through a GUI. However, you can write scripts to access anything from any GUI. For the git example you can make an automator script of type “service” tell it to work on selected files and folders in finder. For your actions choose “Run shell script”. From here you can make a number of these services for git add, git commit, or whatever else you may need. Now from the services menu in finder you can call your git commands. If that isn’t accessible enough for you, you can even assign keyboard shortcuts to them. Using this method you can run terminal programs from anywhere.
A good application of “migrating from the terminal” is the automator service script I wrote for Things. I use Things as my todo list at work and home. Out of the box Things doesn’t have the ability to sync two databases, but using the above method I wrote a simple ruby program to sync them and I run the program from Things service menu. I really feel like apple has done a good job of allowing people to migrate away from the terminal.
Christian,
If someone else can’t supply effective abstractions to use some software, then yes I appreciate having tools that let me build my own abstractions. In my own work, I view this situation as a failure–I have failed in my responsibility as a programmer to provide useful ways of using my software. The users lose in this case and I lose to the extent that I want my software to have maximum impact.
I’m here for only last 10 years, and I’d probably have more reasons to be a GUI guy than a CLI guy, but, jumping around trying to find a working solution for my coding and sysadmin tasks I found my reality that CLI is still a better choice for me. A couple of reasons why I left all the mighty GUI and IDE’s behind was their poor performance comparing to the result you get even on high-end machines that we currently have.
I agree with Till in that “At some point, you stop seeing text and start seeing your vision”, and unfortunately it’s a lot more more than that: an awful lot of programmers stop seeing the code close enough “thanks” to the nice windows of IDE’s and “just create”. I see this as one of the reasons of why the software is slower and slower despite of the fact that we “have four or five orders of magnitude more processing power now”. You don’t really see and value and love your code when the IDE write it for you.
I agree that the learning curve for the CLI & Co. is a little steep but from my experience I can tell that this is rewarded every day of your life marriage with computer. Also: it is consistent on most UNIX systems I’ve worked on, and I believe that this is not a little thing.
Maybe I’ll change my mind in twenty ears too, but I don’t think that CLI requires considerable more mental effort to use than GUI if you got used to it. Exactly as you hit Ctrl+S in your IDE, you do it “:w” in vi. In my opinion, automation power and flexibility of CLI’s still make it a reasonable easy and efficient tool.
Last but not least, the law of Evolution shows us that if CLI is still here, than we probably don’t have a good enough replacement for all its power at an acceptable price in whatever units.
Yes, of course “it depends”.
The power of the command line comes down to two main things for me: 1) the ability to string commands together with the pipe, and 2) the simple “history” facility that allows me to repeat tasks that I did before.
I think item #1 is difficult to replicate in a GUI environment. Item #2 is more challenging in a GUI environment, because I don’t want the GUI to remember keystrokes or gestures; I want a different layer of abstraction. I want it to remember that I did “Refactor method,” not that I right-clicked on a code block and chose the third menu option. But then once it reminds me I did “Refactor method,” I want it to give me a low-level representation where I can change certain parameters.
I suppose the need to remember commands in the first place is a smell that my environment is not doing enough for me, but I think that problem transcends the interface. On the command line, I just find that things are comfortable–I often don’t bother to automate long Unix one-liners since it is so easy to retrieve them from history with control-R and edit them as needed.
Maybe I’m a dinosaur. But I have worked in GUI environments enough to know that they do not solve all my problems.
Steve mentioned stringing commands together with pipes (I assume we’re all talking about the real CLI, Unix’s, not that broken one from Washington). This is a seriously underrated feature of Unix shells: it not only promotes clean interfaces and lots of sharp, special-purpose tools — it also promotes a nearly-functional style of programming called (by Van Roy and Hariri, anyway) Declarative Concurrency. DC has lots of advantages, not least of which is that it’s very, very easy for the operating system to spread it across those four-to-sixteen cores in modern CPUs.
The other thing about stringing commands together in the shell is that you can tell the computer what to do *before* it needs doing — and conditionally, if you use && and ||. With most GUIs, you have to wait for it to finish the first task before you can tell it to do the second task; recording general cases for rerunning is hard. Think of it as a language that allows delayed evaluation vs. one that doesn’t.
Finally, I use a Unix shell (tcsh) inside a buffer in Xemacs. It’s a huge win to be able to search back through not only previous commands, but previous results, and quickly use those textual results any way I want (e.g. sorting the output of “svn status”, then running a keyboard macro on some chunk of it to do the same thing to each file in the chunk). Not least, there’s the comfort of knowing I can scroll back and look at *everything* I’ve done this session to see (a) how to redo it or (b) if I accidentally skipped anything; I even save my old sessions because they’re so frequently useful.
I appreciate GUIs much more for output. Sadly, a lot of obvious graphical representations of things haven’t been written yet, or anyway aren’t very common. Pointing and grunting is the *downside* of a visual communication mode; if you’re going to spend time interacting visually, get the computer to saturate the visual bandwidth, and forget about saying much to it.
(Steve: Did you mistype “Howell”? If so, are you the XPWDC Steve? If so, Hi!)
Hi George, this is indeed the Steve Howell you remember. I also appreciate GUIs much more for output. For example, I bet I could still do a lot on a pure green-screen interface, but I would miss color syntax. For things like charts and graphs, you can still do a lot on the green-screen (ASCII histograms are great!), but they just look better under a modern GUI.
Great article. I agree with the sentiment to a point, except on the following:
First, I think that the disappointment of CLI being “old” because it’s 60 years old is in a sense just age prejudice. I say this as I type on a keyboard invented in the 1800s, using a character set that was invented by the romans a few centuries BC. So don’t fret about the age of CLIs. Paradigms are useful because they’re useful, not because how new they are (as they say in my country, the devil knows more for being old than for being the devil). So the disappointment argument falls flat on its face on that count.
Now disappointment with the rate of change I do understand. I find the reason for the slow evolution has more to do with people not liking to pay for or standardize on development tools just as large dynamic language codebases increase the engineering efforts for doing parse trees and run simulations. So advance is slow, which is not necessarily a bad thing (I find too many “kids these days” who don’t really use a command-line all that well and I think it hurts their understanding of software, sometimes in significant ways).
I do agree that refactoring tools for dynamic languages would be a nice thing. The main thing about putting something in a GUI is the fact that it forces all people into a single train of thought with limited branches, which for creative work can be effective only to a point. So it’s really a matter of finding which trains of thought are good to synthesize and adding features to the CLI for that purpose (command-line tools could be made for some of the typical refactorings – maybe even bundled along with the language – to make integration on all editors easier). The opposite problem is a bunch of GUIs that don’t do piping (*cough* Microsoft *cough*), so there’s no creative ways of automating them.
As for the argument of keeping too many things in your head, remember that it’s not just about your responsibility to your employer, but also about your responsibility to keeping your own brain sharp both for yourself and your present and future employers. You can think of the command line as mental calisthenics, keeping you sharp even as you age. It is expected that with age they become more difficult, but keeping at them, like any exercise, makes them easier (and paradoxically, GUIs tend to make us lazy). Maybe the simpler solution for this is to keep a list of the things that you keep having to remember and coming up with ways to exercise those specifically over and over so they don’t cause you so much trouble, particularly if they are right in the middle of your workflow.
But stretching the mind is good at any age, and the less we stretch our minds the less effective we become, eventually even to the small branches crosscutting our main workflow. Like Hunt and Thomas said in PragProg, if you’ve been using VIM too long, try Emacs. If you have been using the GUI too long, try a commandline. Or viceversa.