Some of my favouite lines. From the Rubaiyat:
We are no other than a moving row
Of Magic Shadow-shapes that come and go
Round with the Sun-illumined Lantern held
In Midnight by the Master of the Show;
But helpless Pieces of the Game He plays
Upon this Chequer-board of Nights and Days;
Hither and thither moves, and checks, and slays,
And one by one back in the Closet lays.
--- Omar Khayyam, The Rubaiyat
Tuesday, February 27, 2007
Return of the Commandline
Here is a search phrase Google accepts:
intext:(google+recruitment+india) intext:(bangalore) filetype:html
This translates to the following more readable form:
“Find pages containing the words Google, recruitment, India in their texts. From amongst these, find the ones that contain the word Bangalore. Finally, from amongst these, get me the pages of type html.”
Though complicated, the above phrase achieves quite a lot in a few words, much like the command line statements UNIX users are accustomed to. In the years before the Graphical User Interfaces (GUI) flooded the software market, this was all we had – plain command lines. With the likes of Google and quite a few other applications encouraging them again (another notable example is yubnub.org) it suddenly seems the command line is slated for a comeback.
GUIs, undoubtedly, have been the dominant form of interface for quite a while. Their greatest advantage is their ease of use over command lines. They are not only easy to learn, but if you have worked on one GUI, you would probably figure out the nuts and bolts of another quite easily. On the other hand, to use command lines efficiently you would require prior knowledge of (probably complicated and cryptic) commands (we are talking a serious learning curve here), with a relatively weaker guarantee that two command line interfaces are going to be similar. Yet, the enormous power of manipulation they offer, make them a formidable contemporary of the GUI and a favorite of developers/administrators (and something that Google hackers swear by).
Fundamentally, what GUIs do is tell users what commands to the system are relevant in the current context of work (apart from graphically displaying the context). For example, if you are on your windows desktop, and right click the mouse, the GUI lists the commands that are relevant here (e.g.”Refresh”, “Arrange Icons”, ”New” etc.). When you are reading a MS-Word document, the GUI now presents the user a host of options to choose from (File related options:”Open”, “Save As” etc. Help related options: “Check For Updates” etc.). And when you right click your mouse over an open ms-word document, the GUI does not list the “Arrange Icons” command this time; It believes that the command is irrelevant in the particular context. Thus a GUI:
(1) is all about clearly defining a context, with a set of user friendly commands (and the user does not need
to know the exact syntax of these commands beforehand)
(2)allows the user to execute a command without actually having him type it in – the command is already out
there, on the screen – an effortless mouse click is all that’s needed to execute it. So, life’s good.
It is interesting to think about whether a command line interface also defines a context. Its very hard to see how, when all you can see is a prompt. What I am driving at is that GUI was probably the first widely popular paradigm that introduced (or at least popularized) the idea of clearly defining contexts. Of course, we take it for granted now. A command line interface is not bound to a context, and thus, in this sense is freer. It has a no-nonsense attitude that basically says you get what you type (and if you mess up, you got what you deserved!).
There are some drawbacks to GUIs though. Scalability is a big one: a GUI is good when we have a small number of commands that you can allow the user to choose from. Bigger the number, more cumbersome the GUI becomes, till a point when you realize that probably a command line substitute might be neater. The nature of this challenge can be guessed when one thinks of implementing the Google search phrase above with a GUI (and, this isn’t just about one search phrase, but the family of such phrases that is accepted by Google).
To take another example lets look at the following situation and decide whether it would be wiser to opt for a GUI as against a commandline: I subscribe to a particular newsletter (via mail). Since I haven’t checked my mails for the past few days, and I plan to store the contents of the newsletters I have received in the period, on my local disk, I would have to mechanically sift through these mails (after I have searched them and got them listed), open each of them and copy the contents onto a local file. And to crown it all, if I am using a trickle-down dial-up connection, this job can be quite exacting in terms of time, money and patience. I don't need much convincing here to realise that this is where I would be right at home with a good command line interface that I can put inside a 'code' or 'pipe' or manipulate somehow (or, if this is something that I do regularly, I might even consider writing a screen-scraping script for it – anything to not depend on the GUI. Of course, we might have a GUI to do this for us, but then that would be a different GUI, with a specialized functions, which only stands on the side of my argument).
Apart from the problem of scalability, the commands displayed by a GUI cannot be used as elements to build “bigger” commands or commands with more functionality (okay, there are macros, but they are more like sequentially defining actions –more on that in a while). That’s to say, the commands cannot be combined together, which restricts a user to the set of commands already provided. Contrast this with the freedom a UNIX shell (the command line interface) provides. Ideas like piping (streaming the output of one command to the input of another – much like the two “intext” criteria that we have used in the sample search phrase above, where the output pages of the first “intext” criterion is considered as input to the second) and command substitution (plugging the command output into another context) remarkably expand the scope of functionalities of existing commands . And what’s more is users can have these commands sequentially executed by listing them in a script – without any intervention needed (returning to macros again, they come close to this behavior, but there’s a lot they cannot do. For example, they usually work within an application, can’t be made to handle errors easily, etc.). Then there's the question of exercising your creativity too - piping/command substitution let you 'create' your versions of a solution to a problem, in a trouble-free way - which, I feel, adds to the excitement of using them.
Summing it up, the GUI as an innovative interface medium has certainly more than fared well. But the GUI revolution has been here for some time and now that we have toyed with it enough to discover its not-so convenient aspects, its probably time we analyzed the command line (again) for its strengths and look for a more promising interface (which proabbly would be the right combination of the two?).
P.S.:
(a)There are a few other factors GUIs and command lines maybe compared with respect to. Some are:
(1) Resource intensiveness: A command line is not as resource intensive (in terms of memory) as
a GUI.
(2) Better Control of OS: Someone who has worked with both the Linux command line and its GUI
will tell you that command line provides better control of the OS.
(3) Multitasking: Both command lines and GUIs can multitask. But GUIs enable surprisingly easy
monitoring of the tasks (Your web browser is downloading a file, while you are happily typing
away into your blog listening
to your favorite band playing – and the great part is you can see all of this happening.)
My thoughts in the post are primarily motivated by the usability of an interface.
(b) For those interested, here’s another article on command line vs. GUIs. This article mentions a project called Enso at www.humanized.com, that aims at integrating a command line to your GUI. That is really putting it very vaguely and to do full justice to the wonderful project you must watch their demo video on the home page. Enso is trying to blur the lines between contexts in a GUI – rather, it tries to define a super-context, that’s a bit of both command line and GUI.
(c) A small aside: are tools making us dumber? An interesting post here.
(d) I recently came across this - a desktop UI system called Oberon - quite interesting to look at since it seems to have taken an evolution path different from most contemporary systems.
intext:(google+recruitment+india) intext:(bangalore) filetype:html
This translates to the following more readable form:
“Find pages containing the words Google, recruitment, India in their texts. From amongst these, find the ones that contain the word Bangalore. Finally, from amongst these, get me the pages of type html.”
Though complicated, the above phrase achieves quite a lot in a few words, much like the command line statements UNIX users are accustomed to. In the years before the Graphical User Interfaces (GUI) flooded the software market, this was all we had – plain command lines. With the likes of Google and quite a few other applications encouraging them again (another notable example is yubnub.org) it suddenly seems the command line is slated for a comeback.
GUIs, undoubtedly, have been the dominant form of interface for quite a while. Their greatest advantage is their ease of use over command lines. They are not only easy to learn, but if you have worked on one GUI, you would probably figure out the nuts and bolts of another quite easily. On the other hand, to use command lines efficiently you would require prior knowledge of (probably complicated and cryptic) commands (we are talking a serious learning curve here), with a relatively weaker guarantee that two command line interfaces are going to be similar. Yet, the enormous power of manipulation they offer, make them a formidable contemporary of the GUI and a favorite of developers/administrators (and something that Google hackers swear by).
Fundamentally, what GUIs do is tell users what commands to the system are relevant in the current context of work (apart from graphically displaying the context). For example, if you are on your windows desktop, and right click the mouse, the GUI lists the commands that are relevant here (e.g.”Refresh”, “Arrange Icons”, ”New” etc.). When you are reading a MS-Word document, the GUI now presents the user a host of options to choose from (File related options:”Open”, “Save As” etc. Help related options: “Check For Updates” etc.). And when you right click your mouse over an open ms-word document, the GUI does not list the “Arrange Icons” command this time; It believes that the command is irrelevant in the particular context. Thus a GUI:
(1) is all about clearly defining a context, with a set of user friendly commands (and the user does not need
to know the exact syntax of these commands beforehand)
(2)allows the user to execute a command without actually having him type it in – the command is already out
there, on the screen – an effortless mouse click is all that’s needed to execute it. So, life’s good.
It is interesting to think about whether a command line interface also defines a context. Its very hard to see how, when all you can see is a prompt. What I am driving at is that GUI was probably the first widely popular paradigm that introduced (or at least popularized) the idea of clearly defining contexts. Of course, we take it for granted now. A command line interface is not bound to a context, and thus, in this sense is freer. It has a no-nonsense attitude that basically says you get what you type (and if you mess up, you got what you deserved!).
There are some drawbacks to GUIs though. Scalability is a big one: a GUI is good when we have a small number of commands that you can allow the user to choose from. Bigger the number, more cumbersome the GUI becomes, till a point when you realize that probably a command line substitute might be neater. The nature of this challenge can be guessed when one thinks of implementing the Google search phrase above with a GUI (and, this isn’t just about one search phrase, but the family of such phrases that is accepted by Google).
To take another example lets look at the following situation and decide whether it would be wiser to opt for a GUI as against a commandline: I subscribe to a particular newsletter (via mail). Since I haven’t checked my mails for the past few days, and I plan to store the contents of the newsletters I have received in the period, on my local disk, I would have to mechanically sift through these mails (after I have searched them and got them listed), open each of them and copy the contents onto a local file. And to crown it all, if I am using a trickle-down dial-up connection, this job can be quite exacting in terms of time, money and patience. I don't need much convincing here to realise that this is where I would be right at home with a good command line interface that I can put inside a 'code' or 'pipe' or manipulate somehow (or, if this is something that I do regularly, I might even consider writing a screen-scraping script for it – anything to not depend on the GUI. Of course, we might have a GUI to do this for us, but then that would be a different GUI, with a specialized functions, which only stands on the side of my argument).
Apart from the problem of scalability, the commands displayed by a GUI cannot be used as elements to build “bigger” commands or commands with more functionality (okay, there are macros, but they are more like sequentially defining actions –more on that in a while). That’s to say, the commands cannot be combined together, which restricts a user to the set of commands already provided. Contrast this with the freedom a UNIX shell (the command line interface) provides. Ideas like piping (streaming the output of one command to the input of another – much like the two “intext” criteria that we have used in the sample search phrase above, where the output pages of the first “intext” criterion is considered as input to the second) and command substitution (plugging the command output into another context) remarkably expand the scope of functionalities of existing commands . And what’s more is users can have these commands sequentially executed by listing them in a script – without any intervention needed (returning to macros again, they come close to this behavior, but there’s a lot they cannot do. For example, they usually work within an application, can’t be made to handle errors easily, etc.). Then there's the question of exercising your creativity too - piping/command substitution let you 'create' your versions of a solution to a problem, in a trouble-free way - which, I feel, adds to the excitement of using them.
Summing it up, the GUI as an innovative interface medium has certainly more than fared well. But the GUI revolution has been here for some time and now that we have toyed with it enough to discover its not-so convenient aspects, its probably time we analyzed the command line (again) for its strengths and look for a more promising interface (which proabbly would be the right combination of the two?).
P.S.:
(a)There are a few other factors GUIs and command lines maybe compared with respect to. Some are:
(1) Resource intensiveness: A command line is not as resource intensive (in terms of memory) as
a GUI.
(2) Better Control of OS: Someone who has worked with both the Linux command line and its GUI
will tell you that command line provides better control of the OS.
(3) Multitasking: Both command lines and GUIs can multitask. But GUIs enable surprisingly easy
monitoring of the tasks (Your web browser is downloading a file, while you are happily typing
away into your blog listening
to your favorite band playing – and the great part is you can see all of this happening.)
My thoughts in the post are primarily motivated by the usability of an interface.
(b) For those interested, here’s another article on command line vs. GUIs. This article mentions a project called Enso at www.humanized.com, that aims at integrating a command line to your GUI. That is really putting it very vaguely and to do full justice to the wonderful project you must watch their demo video on the home page. Enso is trying to blur the lines between contexts in a GUI – rather, it tries to define a super-context, that’s a bit of both command line and GUI.
(c) A small aside: are tools making us dumber? An interesting post here.
(d) I recently came across this - a desktop UI system called Oberon - quite interesting to look at since it seems to have taken an evolution path different from most contemporary systems.
Subscribe to:
Posts
(
Atom
)