Linked by David Adams on Fri 5th Aug 2011 16:08 UTC
Graphics, User Interfaces A couple of days ago I read a blog post by Stephen Ramsay, a professor at the University of Nebraska-Lincoln and a Fellow at the Center for Digital Research in the Humanities. In it, he mentions that he has all but abandoned the GUI and finds the command line to be "faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible than even the most well-thought-out graphical apps." I found this very thought-provoking, because, like Ramsay, I spend a lot of time thinking about "The Future of Computing," and I think that the CLI, an interface from the past, might have a place in the interface of the future.
Thread beginning with comment 483870
To view parent comment, click here.
To read all comments associated with this story, please click here.
TemporalBeing
Member since:
2007-08-22

VSD is also extendable via scripting and plugins. For example, Boost publishes a text file that allows to better visualize some of its common classes (e.g. shared_ptr, optional, etc).

I've never seen any developer truly using the extension capabilities of either GDB or VSD.


Yes, extending VSD is not very common.
Extending GDB is far more common than you may realize as its part of how you efficiently use GDB.

It's the Hello World problem all over again. No matter how powerful a language or an interface is, if it takes 200 lines to print a 'hello world', it won't get popular.


May be for VSD. But it's quite easy with GDB - it's a simple function - so may be 4 lines of code to do 'hello world'.

CLI vs GUI is for me the same problem. It doesn't matter how powerful CLI can get, if 99% of the base usages are less efficient.


At the same time, GUIs are only as powerful as they are made to be, and often are not powerful enough.

Take the Google Map example and the SQL-like CLI that Alfman posted below. Sure it's extremely powerful, but it fails to consider the information consolidation that such interface lacks:
<snip>


Google Maps is certainly one thing that is designed for and can only really be operated by GUI, and one that can be augmented through scripting (ala its JavaScript APIs).

In all, there are typically four realms of software:
1. Software that has no user interface
2. Software that only has a CLI
3. Software that only has a GUI
4. Software that has a CLI or GUI but is really only good with one of them (which may be either).

Google Maps certainly falls into #3.

There is no way a CLI can get close to the efficiency of a GUI interface. As the GUI can provide a tighter integration to several multidimensional concept that a CLI can't (at least no so easily).


Whether or not a CLI or GUI is more efficient is wholly dependent on the design and interface of each.
Many times a GUI is simply a wrapper around a CLI, dumbing down the CLI for people that don't want to deal with all the work - example: cd/dvd/bd burning on Linux typically is a wrapper around a series of command-line programs that make it easy to gather the data to pass to the program.

However, CLIs can also be very easy to use and extremely efficient. That is the nature of the interfaces on a *nix system - that's how *nix systems are tied together. Some programs (e.g. sed, perl, grep, find) are more complicated while others (e.g. if, [[, ]], then, test) are extremely simple, and yet others (e.g. bash, ash, dash) provide the glue to bring it all together.

Now comparatively, the DOS Batch vs. PowerShell is a whole other world. PowerShell is way too complicated to do anything useful. DOS Batch was rather simple, but well underpowered - namely due to the limitations therein imposed.

The reason I cited TortoiseSVN was for similar reason. Sure the CLI is more powerful. But on a realistic situation, the information integration provided by the GUI is simply superior for most usages.


SVN CLI is very very simple. TSVN is also very very simple. And yes, TSVN is great for 90% of use cases; but there are times (e.g. some merges) when it is just easier to use the CLI - and far less steps too.

SVN CLI is very efficient.

However, unlike other things - like TortoiseCVS - TSVN is not simply a wrapper around the SVN CLI. SVN is, rather, by design a library that is integrated into multiple things directly. So TSVN uses the library and provides one style interface; while SVN CLI uses the same library and provides a different interface. But that's simply the design of SVN and why it is so well extensible.

(Other software, like eSVN, WinSVN, etc sadly do not make proper use of the library and have become simple wrappers around the SVN executables.)

As another user posted, the CLI requires you to know exactly what you want and how to express it precisely. However, most of the time problems are fuzzy. You roughly have an idea of what you want, but you're not fully sure how to get there.


That, again, depends on the CLI interface.

As I said - CLI vs. GUI very much depends on the design of the interface of each. Searching is rather fuzzy, and hard to get right in a GUI interface. It's equally hard with a CLI interface; and neither really do it right.

Taking TSVN as an example again, the GUI makes it a lot easier to manage the working copy and it's associated server side repository as the user does not have to remember by heart all the URLs. He can browse to the location he wants and then directly access the available operations on it.


That same info is easily available from the SVN CLI too - pretty much in the same manner. Whether using 'svn list' to look at the repository, or 'svn info' to look at a working copy. Better yet, 'svn property edit' will use your favorite editor - whether vi, notepad, emacs, nano, etc. TSVN, OTOH, only lets you select different diff & merge tools.

The human brain retains 9 times more information when visually presented or visually supported (in contrast to text or speech). Knowing that, it's hard to defend that CLI is superior to GUI in general.


However, you can't script a GUI nearly as well.
Sure there are some things out there that can do it (e.g. DejaGNU can for testing GUIs), but it just doesn't work very well.

Scripting CLIs can work extremely well when you have the right environment - which the Windows Command Shell is not.

Take finding a file on disk for example. A GUI interface can provide a basic search functionality, even integrate RegEx. But you're limited by the abilities of the GUI.

Comparatively, with a CLI you can pipe numerous aspects together - include this, exclude that, apply this filter, etc. This is something that even the most advanced GUI searches are unable to do. Yet CLIs do it extremely efficiently.

Ultimately neither is CLI or GUI is necessarily superior for any given task with few exceptions (e.g. Google Maps) - it's a matter of your tools. As such, arguing that one or the other is superior is an endless and useless argument.

Reply Parent Score: 3