His comments about cognitive load are valid, and a real concern---a good interface needs to let you focus on the core stuff and not make you remember everything about everything. There are two big weaknesses, though, at slightly different levels of interface.<p>At the input level, he seems to forget that keyboards (with somewhere between 50 and 100 keys that I can strike exactly and digitally) are fundamentally a better input interface for expert operations than the mouse/trackpad/pointer (with a rasterised but basically more analog feel that makes me "look where I'm going"). GUIs are great but there are relatively few that have the level of keyboard control that you can get with a terminal-based app.<p>The second is that text apps let me give commands with arguments much more straightforwardly; there is a <i>language</i> I speak, where GUI-based stuff is more like grunting and pointing. Clicking a mouse on a button or menu item is like calling an argumentless function(). Maybe you highlight something first and it's more like an argumentless selection.method(). Being able to type your command out, if it's at all complex, is just simply more powerful, and so text-based interfaces aren't going away any time soon.
A seasoned CLI user will trump a seasoned GUI user every single time for the majority of tasks.<p>Take a task like thumbnailing every image in a directory to a certain size. With CLI it's just looping over convert(1). With GUI you have to clicky-clicky to get to the directory, drill down to the options, swap to keyboard to enter sizes, etc.<p>Not to mention the richness of CLI options mean that an equivalent GUI offering would be insanely complicated. Try designing a GUI frontend for sed or awk. Or a file rename utility that matches Emacs Wdired mode in power and (interface) simplicity.<p>Configuration: changing a text file vs clicking on/off a checkbox. You can write a tiny script that flips options between two configs you like, versus more clicky-clicky. You can copy configs around, diff them, grep them.<p>tl;dr - yes CLI has more cognitive load (in that you need to be more familiar with your tools vis-a-vis GUI equivalents), but you get so much more in return.<p>EDIT: quick list of CLI utilities if anyone is interested<p>* feed reading: newsbeuter<p>* music playing: ncmpcpp+mpd<p>* irc/im: irssi+bitlbee<p>* torrents: rtorrent<p>* git browser/pager: tig<p>Many more here: <a href="http://cli.homelinux.net/CLIapps.html" rel="nofollow">http://cli.homelinux.net/CLIapps.html</a>
There's stories about tablets and so on recently, so that got me thinking a little bit about what input devices would be like N years into the future?<p>For programmers, are mouse and keyboard still going to be king? I can imagine that maybe the mouse could be replaced or supplemented by a camera that matches where you're looking at to a cursor position. This should be faster than mousing around.<p>For text input the options are a keyboard or voice input/brain input. I don't think the majority will move from QWERTY anytime soon, and voice input may not take off for the simple reason that you're making noise. Brain input might be interesting.<p>As for any fancy ways of generating programs (plugging components together), you will likely still need to go to a textual level to capture all the detail, so no real application for anything touch sensative there.<p>As for what form a keyboard might be, your touchpad could generate a virtual keyboard when you need it (and have smart materials to give tactile feedback) and fade back to a touch system when you don't need text input.<p>I imagine you'll still need an ergonomic setup and regular breaks to avoid occupational overuse syndrome.
what i find interesting are the places where cli and gui are merged in such a way that uses (at least some of the) strengths of each. on the mac, i use quicksilver, which is kind of a gui for text-entry commands. adobe indesign and netbeans ide each have a drop-down field that's invocable by keyboard shortcut that allows you to directly access options and settings hidden in various menus and palettes by typing a few letters and arrow keys. the firefox plugin ubiquity also has these qualities, and firefox has find while you type built in. these are not terminal equivalents by any stretch, but they are real time-savers, and show the mouse up for the burdensome appendage that it is (forgive my exaggeration). i think if more gui designers and gui programmers would adopt this approach, computer interface design would move forward, imho, in a more useful and more interesting way, instead of slavishly using real-world object metaphors such as the desktop.
I disagree with this. If you have a GUI, sure, you have fun buttons to click. But if you don't understand what those buttons actually do, you will mess things up if you click them without thinking. The solution to this is to read the documentation and understand what you are doing.<p>If you don't have a GUI, then you will have to read the manual to find out what to do.<p>The end result is the same; you have to read the manual.<p>(Also, you can have discoverable interfaces without graphics. Open a file in Emacs and type M-x describe-mode. From there, you have a description of the commands available, and links to follow for more details about any aspect.)