Ode to the Command Line
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.
E-mail Print r 7   · Read More · 58 Comment(s) http://osne.ws/jbf
Thread beginning with comment 484162
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Two distinct beasts...
by WorknMan on Tue 9th Aug 2011 02:42 UTC in reply to "RE[3]: Two distinct beasts..."
WorknMan
Member since:
2005-11-13

All types of problems crop up: When suddenly an error message is displayed, when the dialog flow changes because of some unforeseen state, when timing issues crop up.


I've never had an issue with timing when using controlsend to a certain widget/id. But, as you state, you may have to make some minor modifications if/when a new version is released and the developer changes things that directly affects your script, but wouldn't that be the case for CLI apps as well, if they change the command-line syntax?

Of course, GUI automation isn't the ideal way to get things done; I was just pointing out that it's not exceedingly difficult either, and certainly not impossible. In fact, I do it all the time ;)

Edited 2011-08-09 02:44 UTC

Reply Parent Score: 2

benjymouse Member since:
2011-08-06

but wouldn't that be the case for CLI apps as well, if they change the command-line syntax?

The difference is that there is absolute no obligation on the developer to keep widget types and/or -id's stable across versions, much less behavior.

The developer of a CLI command has the option of introducing new parameters as non-breaking changes, or an entire new command if breaking changes are needed. That can keep the old command running.

More importantly, the developer of a CLI tool understands that she has an obligation to carefully avoid breaking changes as much as possible. Having some script depend on the tool is the *norm*. That is not the case with GUI keyboard/mouse-automation.

Of course, GUI automation isn't the ideal way to get things done; I was just pointing out that it's not exceedingly difficult either, and certainly not impossible. In fact, I do it all the time ;)


I have no doubt that it is possible (with some work). But as I pointed out it is not something you can build stable scripts (stable over time) upon. And the scripts tend to be horrible and have very poor error handling.

Reply Parent Score: 1