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 483848
To view parent comment, click here.
To read all comments associated with this story, please click here.
TemporalBeing
Member since:
2007-08-22

Another example I can think of as a programmer is GDB versus Visual Studio Debugger.


Having used both, I'd say they are equally powerful as each has their faults that are the others strength's.

For simple debugging, VSD is a great tool. But you can't get the same kind of in-depth diagnostics or extensions as GDB.

VSD doesn't have a scripting language, or even a API that many others can use - i.e. you're stuck with MSVS, WinDebugger, or one of the few other GUIs provided by MS to utilize VSD - and you can't extend it very easily at all.

GDB, OTOH, has a full API that a number of different applications use to provide a GUI on top of it - some of which are very similar to VSD.

But even if you want to stick with the CLI, GDB has a fully programmable interface through an internal scripting capability, and even the ability to support Python additions.

So where in VSD you would have to see that array[1].d->array is a string (to borrow from Qt's QString), in GDB you can add support for them via one of two interfaces so that array[1] just shows a string when you call 'print', and you can access its functions too - e.g. array[1].size(). VSD has not equivalent extension capability - where it can be extended requires extensive work to support through customized DLLs.

Another would be SVN CLI versus TortoiseSVN.


This is more a case where the main project (SVN) does not want to implement certain features, but enables derived projects (e.g. TSVN) to do so easily, and those derived projects decide to do so.

In other cases, it is simply that the GUI makes it easier to follow a work flow process.

That said, I still tend to use the SVN CLI over TSVN for more complex things as it is simply more straight forward. (And I started using SVN via TSVN.)

Each time the GUI version presents the information in a better way to the user, and ironically also provides more features.


Sometimes yes, sometimes no. In both your examples they both have trade-offs, strengths, and weaknesses - some of which you seem to have overlooked.

So I'd still have to agree with TFA as the more advanced functionality that even non-power users would find very useful is typically in the CLI program - GDB and SVN - in easier to use methods should the GUI support it at all.

Reply Parent Score: 6

gpsnoopy Member since:
2007-04-17

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.

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.

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.

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:

- in Google Maps I can easily see where I am and where I roughly want to go. I can drag and drop the source and destinations with the tip of my finger. I can go into street view just by two finger-pushes, and find my view around town, visualizing the neighborhood before I even got there. Oh, and why not make a restaurant reservation via Google Map while I'm at it. Once I'm done, I can email it to a friend with 3 clicks.

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).

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.

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.

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.

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.

Reply Parent Score: 1

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