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 483839
To read all comments associated with this story, please click here.
A bit optimistic and naive...
by gpsnoopy on Fri 5th Aug 2011 17:23 UTC
gpsnoopy
Member since:
2007-04-17

If you think about it, any CLI is just yet another programming language. Sure, there are problems that can be easily solved by CLI. But to think that a text based approach will quickly solve all problem is a bit naive.

CLI is very good at being very specific about what you want, and more importantly chaining (e.g. pipes) existing tools to create a new procedure. Again, this is just yet another programming language...

But if everyone uses GUI nowadays, it's not just because they are too stupid to understand CLI. GUI can present multidimensional information much more easily, and the user can interact with it very intuitively. Think about Google Map on a touch based device, how do you do that in CLI?

Another example I can think of as a programmer is GDB versus Visual Studio Debugger. Another would be SVN CLI versus TortoiseSVN. Each time the GUI version presents the information in a better way to the user, and ironically also provides more features.

If you're looking for a quick procedural approach to solve a problem then CLI is great. If you have to deal with any form of multidimensional information that's not quickly and easily filtered, then no, CLI is not what you want.

Reply Score: 2

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

Alfman Member since:
2011-01-28

gpsnoopy,

"But if everyone uses GUI nowadays, it's not just because they are too stupid to understand CLI. GUI can present multidimensional information much more easily, and the user can interact with it very intuitively. Think about Google Map on a touch based device, how do you do that in CLI?"

For consuming visual media, obviously you need a visual interface, I don't think anybody's claiming otherwise.

But for interacting and manipulating that information, some people may still prefer a CLI. Using your example, let's suppose we have a command line tool to query google maps (allow me to making this up as we go along):

select route from roads where route.orig='san fransisco, CA, USA' and route.dest='new york, ny, usa' order by route.time

Hmm, not as nice as the GUI, but what else can we do with it?


select concat(a + b + c) from roads a, flights b, roads c where a.orig='...' and c.dest='...' order by concat(a+b+c+d).distance and b.fair<150 order by time


Clearly we'd need to rethink the sql metaphor, but the point is this would be incredibly powerful. We could write very complex queries to implement use cases which the GUI designers had never anticipated (or would have found too difficult represent visually).

Would this CLI have a large learning curve? Absolutely, but those who learn it would have so much more power over the information at their hands.


Edit: Just to clarify, my use of "CLI" here is refers to a command oriented interface, whether or not the interface is part of a larger GUI.

Edited 2011-08-05 18:18 UTC

Reply Parent Score: 3

jabbotts Member since:
2007-09-06

I actually miss the days of viewing images with Alchemy in Dos. It was like magic to see what was always an ascii/ansi text environment showing full colour photos.

These days, there are times when I'd really like to just pop open an browser, video or image without having to load into a full GUI.

(I know viewing video can be done, I just haven't looked into it yet.. more interesting projects ahead of it on the list)

Reply Parent Score: 2