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.
Permalink for comment 483848
To read all comments associated with this story, please click here.
Member since:

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