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.
Order by: Score:
Two distinct beasts...
by zima on Fri 5th Aug 2011 17:00 UTC
zima
Member since:
2005-07-06

Command line, CLI, with its usually a bit arcane commands, is a somewhat different concept from natural language interpretation. Treating them as very related (considering the topic used above, mentioning the CLI repeatedly; contrasting them both with GUI...) is possibly counter-productive.

As a side note, IIRC there were also some research suggesting that, in many scenarios, CLI merely is perceived as faster than GUI (supposedly because CLI requires greater attention, which masks perception of time); but actually timing some common tasks tells otherwise.

And scifi "computers" are mostly just a storytelling tool, to woo the audiences with cheap tricks...

PS. Winphone7 is a more real-life example to consider. Very text based. But TBH... I'm not entirely convinced it fits the way our minds work (particularly with the early demonstrations of WP7, I can't get rid of the feeling that the presenters appear relatively lost; people who were meant to promote the product, show how nice it is, hence supposedly familiar with it). It took us some time to get decent ~WIMPy paradigms, and maybe they are what works for humans... (obligatory car analogy: kinda like it took some time to develop the steering wheel; since then, no "refirement" was able to replace it; maybe autonomous cars can change that, maybe a central "swinging joystick" controller would be a fit in them - but that would be only because of very different overall approach, almost like "computer, do what I want to be done, so that I don't have to (authorisation: 8295 somebody-who's-not-quite-sure-why-he-is-needed-onboard)")

Edited 2011-08-05 17:20 UTC

Reply Score: 2

RE: Two distinct beasts...
by Alfman on Fri 5th Aug 2011 17:45 UTC in reply to "Two distinct beasts..."
Alfman Member since:
2011-01-28

zima,

"As a side note, IIRC there were also some research suggesting that, in many scenarios, CLI merely is perceived as faster than GUI (supposedly because CLI requires greater attention, which masks perception of time); but actually timing some common tasks tells otherwise."

This is desperately asking for a citation.


My thought is that it is true that CLI apps have a higher learning curve, but knowledge of them pays off very quickly.

To the extent that GUI are inherently a superset of CLI, then in theory GUI should be every bit as good as CLI. However in practice GUI programs are incredibly difficult to automate. It's usually quite trivial to perform automation on top of CLI, and incredibly difficult with GUI apps.

We could always say that this is a weakness of the specific GUI program, which failed to incorporate macros, rather than a problem with the GUI model in general. However this is something many CLI apps get for free.

Even something as simple as renaming many files is error prone and painful without CLI tools.

You might need to replace "Company" with "Company, Inc" in all documents where it hasn't already been changed. If your documents are only accessible through a GUI interface, then you (or the intern) might need to spend several hours doing it manually.

Reply Score: 5

RE[2]: Two distinct beasts...
by zima on Fri 5th Aug 2011 18:57 UTC in reply to "RE: Two distinct beasts..."
zima Member since:
2005-07-06

Don't make out of it anything more than I wrote and you quoted (which includes "side note", "IIRC", "suggesting", "many" (!="most" for example); what is essentially everything I remember about it (well, plus how it was some research with a downloadable pdf, I think; and perhaps how it included more real-life, poorly-structured, end-user file management).

(so it's also not about finding an almost absolute edge case counterexample - simple, almost "atomic", highly repeatable text edit of every file at hand, what batch editing is pretty much about)

Seeing GUI as a superset of CLI is probably also not particularly helpful, when tons of data people care about doesn't really exist in textual form, but in graphical (sure, pedantically we might go down to how it is represented under the hood, but...)

That's kinda related to what I was pointing at, unnecessarily rigid distinctions and/or grouping of concepts. For example, is Google - or, even better, GMaps - a graphical or textual UI?

Well... both. It would be mostly quite horrible when presented and manipulated in a usual pure CLI fashion. But you do input textual commands (there's just no reason for them to be very CLI-like); and with routine automation even expected to be hidden by nice GUI, here and there.

Edited 2011-08-05 19:11 UTC

Reply Score: 1

RE[3]: Two distinct beasts...
by steogede2 on Fri 5th Aug 2011 22:29 UTC in reply to "RE[2]: Two distinct beasts..."
steogede2 Member since:
2007-08-17

Seeing GUI as a superset of CLI is probably also not particularly helpful, when tons of data people care about doesn't really exist in textual form, but in graphical (sure, pedantically we might go down to how it is represented under the hood, but...)


You do realise he said "superset" not "subset"?

Reply Score: 1

RE[2]: Two distinct beasts...
by WorknMan on Fri 5th Aug 2011 19:36 UTC in reply to "RE: Two distinct beasts..."
WorknMan Member since:
2005-11-13

To the extent that GUI are inherently a superset of CLI, then in theory GUI should be every bit as good as CLI.


Well, GUI is not inherently a superset of CLI - it's a COMPANION. Meaning, each is better at some tasks than the other, so they go together like sugar and kool-aid, and I wouldn't be without either. Why must everything be turned into a pissing contest?

When it comes to GUIs, some have said how it's easier to pull up files in a CLI, like when you need to copy all files that are older than a certain date and with a certain extension. But what if you need to copy about 50 random files from a directory of 300 files that don't have any specific pattern to them? In that case, it's easy to CTRL+CLICK select the ones you need and drag them wherever. Similarly, the article mentions how it would be easier to manipulate music playlists, but what if you've got a playlist with 300 songs, and you want to custom sort them? Again, it's going to be easier to just drag stuff where you want them.

Of course, one could list dozens of examples were CLIs would be more useful... as I said before, it's not about which one is 'better', because that depends on the context.

However in practice GUI programs are incredibly difficult to automate.


Actually, no it isn't... at least on Windows, it's quite easy:

http://www.autoitscript.com/site/autoit

The only exception to this is if apps don't use standard widgets, which is one of about 486472343 reasons why I'm a fan of standards in this regard. Of course, on Linux, this would never work, since the general assumption seems to be that having 900 different toolkits is a good thing. So if GUI automation is hard, it's probably because of a piss-poor implementation, or someone hasn't written the tools to do it. But doesn't that work the same way on CLIs? I mean, SOMEONE has to build in pipes and stuff if you really want to do something useful with it ...

Reply Score: 4

RE[3]: Two distinct beasts...
by dragos.pop on Mon 8th Aug 2011 14:57 UTC in reply to "RE[2]: Two distinct beasts..."
dragos.pop Member since:
2010-01-08

Of course, on Linux, this would never work, since the general assumption seems to be that having 900 different toolkits is a good thing. So if GUI automation is hard, it's probably because of a piss-poor implementation, or someone hasn't written the tools to do it. But doesn't that work the same way on CLIs? I mean, SOMEONE has to build in pipes and stuff if you really want to do something useful with it ...


Not necessary... it would work, but you have to chose the solution made for the toolkit that your app is build upon. Plus sending key and mouse events might work the same on all toolkits (but the recognition of widgets is not so portable).
Plus Qt offers an easy way to integrate scripting into your app (if it is open source or you are developing it).

Reply Score: 1

RE[3]: Two distinct beasts...
by benjymouse on Mon 8th Aug 2011 17:03 UTC in reply to "RE[2]: Two distinct beasts..."
benjymouse Member since:
2011-08-06

Actually, no it isn't... at least on Windows, it's quite easy:

http://www.autoitscript.com/site/autoit

The only exception to this is if apps don't use standard widgets, which is one of about 486472343 reasons why I'm a fan of standards in this regard.


Relying on widget types and -IDs for automation is inherently error prone and extremely brittle. I can never be more than a band-aid in the absence of a real automation framework.

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. Not to mention how enormously difficult it is to have robust error control in such an automated script. Or when a new version is released and IDs or widget types changes, when drop-down boxes doesn't contain the expected (and hard-wired) values. etc. etc.

Of course, on Linux, this would never work, since the general assumption seems to be that having 900 different toolkits is a good thing. So if GUI automation is hard, it's probably because of a piss-poor implementation, or someone hasn't written the tools to do it. But doesn't that work the same way on CLIs? I mean, SOMEONE has to build in pipes and stuff if you really want to do something useful with it ...


I wouldn't fault Linux for this. You were never supposed to rely on widget types and/or ID in the first place. The only ones who can reliably use those are the very developers of the apps who can use it for automated testing. The rest of us should stay away from it.

A much better solution is being developed with PowerShell. PowerShell "cmdlets" are suitable for sharing implementation with GUI application "command" patterns. Indeed this is what Exchange and several other MS server apps do now: They implement the cmdlets *first* and then build a GUI on top of those. The GUI then becomes the composition tool for PowerShell command pipelines.

The Exchange admin GUI will even show you the very PowerShell command pipeline it will execute and let use cut-and-paste it for automation.

PowerShell cmdlets are designed (unlike the typical *nix shell) for in-process execution, hence they can consume and produce strongly-typed in-process objects which makes it much more usable for actual GUI automation. In essense the GUI becomes a way to combine and design CLI commands.

Reply Score: 1

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 Score: 2

RE[5]: Two distinct beasts...
by benjymouse on Tue 9th Aug 2011 20:18 UTC in reply to "RE[4]: Two distinct beasts..."
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 Score: 1

Macbook Wheel
by Alfman on Fri 5th Aug 2011 17:03 UTC
Alfman
Member since:
2011-01-28

http://www.youtube.com/watch?v=R8gF0KTfMrQ

My apologies in advance for being the first to bring up apple, but I think it's relevant!

Reply Score: 3

RE: Macbook Wheel
by jello on Fri 5th Aug 2011 18:59 UTC in reply to "Macbook Wheel"
jello Member since:
2006-08-08

In this video is mentioned that one guy spent 45 minutes writing an email to his friend with this Macbook Wheel, and then they show a 2 sentence email...

Also the Hummingbird battery coming with this $2600 laptop can power the computer for almost 20 minutes...

One must really be an Apple fan-boy to call this progress...

Maybe this video is a joke and not portraying an official Apple product...

Reply Score: 2

RE[2]: Macbook Wheel
by viton on Fri 5th Aug 2011 19:36 UTC in reply to "RE: Macbook Wheel"
viton Member since:
2005-08-09

Maybe this video is a joke and not portraying an official Apple product...
Bingo!

Reply Score: 4

RE[2]: Macbook Wheel
by ebasconp on Fri 5th Aug 2011 22:01 UTC in reply to "RE: Macbook Wheel"
ebasconp Member since:
2006-05-09

I think the problem is that you cannot embed a youtube video inside the <sarcasm> and </sarcasm> tags ;)

Reply Score: 2

RE[2]: Macbook Wheel
by benb320 on Fri 5th Aug 2011 23:10 UTC in reply to "RE: Macbook Wheel"
benb320 Member since:
2010-02-23

you thought that was real!?!? haha it is not, it is a joke video made by the onion news network, look them up, they have some pretty funny stuff!

Reply Score: 1

RE[3]: Macbook Wheel
by mrstep on Sat 6th Aug 2011 22:03 UTC in reply to "RE[2]: Macbook Wheel"
mrstep Member since:
2009-07-18

Given it's fake, but they really did a great job with it. I love my Apple products, but getting rid of the keyboard and replacing it with a click-wheel was a classic.

Along those lines, sometimes you see these 'how do I fix XXXXX in iTunes", and half the time the answer is 'hold cmd-option while launching it' or 'press option while clicking on the Update button'. Uh... I know it's just me, but when did having invisible options become easier than just putting those under a 'Advanced' options pane somewhere for doing special tasks that most people don't need to see? Totally hidden is easier? Really?

And that's where the Onion video got it so right!

Reply Score: 1

RE[2]: Macbook Wheel
by clasqm on Sat 6th Aug 2011 06:06 UTC in reply to "RE: Macbook Wheel"
clasqm Member since:
2010-09-23

See the date it was uploaded: April 1, 2009

Reply Score: 1

RE: Macbook Wheel
by SilConGeeky on Sat 6th Aug 2011 07:34 UTC in reply to "Macbook Wheel"
SilConGeeky Member since:
2011-08-01

Love the ending part.. "not just dicking around"

Reply Score: 1

RE: Macbook Wheel
by Neolander on Sun 7th Aug 2011 22:20 UTC in reply to "Macbook Wheel"
Neolander Member since:
2010-03-08

Also possibly relevant : http://www.youtube.com/watch?v=GdIanqM_RZ8

Reply Score: 1

Unfortunately, it will always 'ls -l'
by whartung on Fri 5th Aug 2011 17:22 UTC
whartung
Member since:
2005-07-06

It may be some different switch, or some longer expression, but it's always going to be specific, nit picky and pedantic. It will also be equally "undiscoverable", which is the primary complaint against CLI.

GUIs are basically discoverable for most domains. Specific vertical applications (e.g. 3D modelers) have so many new concepts that outside training and information are required simply to understand what options might be available in the interface. Without that domain knowledge, discoverability isn't useful.

But with that knowledge, the GUI opens up many of the options by presenting them in front of the user. Click around and find what you want to do, or discover something new.

Most modern command lines don't have that, the Unix one especially. Not easily.

If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.

But either way, regardless of how you learn about an action, representing that action to the machine will be a detailed request. There are always defaults ('ls' vs 'ls -l') but that last thing that you want to do with a computer is have a conversation with it. You don't want it asking you questions, validating your choices. That's what makes the command line efficient. It does what it's told. But to tell it correctly, you have to be very specific.

Consider examples from the real world.

I eat at "In-N-Out", which is a burger stand. I know exactly what I want, and I've honed my ordered to work within their system to make it as efficient as possible. "Double double, lettuce, tomato, grilled onions only." I've learned this, USUALLY, expresses exactly what I want with little interpretation. I could order it "double double, no sauce, grilled onions", which is the same end result, but they almost always came back with "you want ketchup or mustard instead". A needless question, but obviously I'm not clear enough.

Still, I occasionally get the the server who asks the ketchup question.

Similarly, with generic drive through, I follow a specific regimen for the order. I make the basic order "#1 please". Then I wait for the questions. Why don't I just say "#1, hold the cheese, large fries, and a coke"? That's what I want. But a combination of the order speaker, the noise inside, the skill of the server trying to work the machine (which is very specific) inevitably overloads them and they just ask these questions anyway. So, I let them pace the order. In-N-Out tends to have a simpler system and better training, most restaurants don't.

Finally, when ordering eggs, order them "scrambled well" vs "scrambled hard". "Hard" gets conflated with "over hard", you say "scrambled hard", and either server hears "eggs hard" or the cook misinterprets it and you get the wrong result.

The point of this diversion is simply that even when involved with human communication, you have to be very specific. And computers are a) much worse at interpreting people and, moreso, folks hate 'interacting" with computers more than anything (witness the general praise for voice response applications).

The command line is great when you know exactly what you want, as it's very precise and concise. The problems with "-l" etc. are really secondary, because folks in time want those abbreviations.

Most any user would loathe being forced to routinely type:

list files with full description sorted by modification date in descending order.

Maybe some context, maybe always doing what it did last time. Remember options all the time, having really good defaults and simple setting and reseting and overriding of those defaults. But then everyones experience becomes different. When your "ls" is different from my "ls", expect support to explode.

Computers are hard to use. They're awful. Truly awful. But, then, so is everything else. Communication is hard, ask any married couple. How can you expect better from complete strangers and machines?

Reply Score: 9

righard Member since:
2007-12-26

If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.


Can can do 'info'.

Reply Score: 2

pepper Member since:
2007-09-18

> list files with full description sorted by modification date in descending order.

Excellent example. When was the last time you *needed* to list all files sorted by modification time? Because I can't remember such a time. I'm always amazed how people browser their files by *manually* searching the list presented by their computer. I thought computers are meant to do the searching for you?

Many even don't know they can just start typing the first characters of the file if they know its name. By just browsing and clicking on names, they also usually don't know how the files and folders are called, they only learn to recognize them when they see them.

For most purposes, I find GUIs horribly slow and inefficient. I use them for graphics work and browsing, I didn't find good CLIs in those areas or they were too expensive to learn (e.g., I still use GIMP only once a year, so I'm not going to learn the shortcuts there..).

Reply Score: 1

_txf_ Member since:
2008-03-17

Excellent example. When was the last time you *needed* to list all files sorted by modification time? Because I can't remember such a time.


I use it quite often. If you can't remember the name of the file but can remember the time you used it, then modification time helps. It even helps when you cannot remember exactly when you last used it by looking for it as an offset relative to a file that you do remember modifying.

Just because you don't use it, doesn't mean it isn't valid.

Reply Score: 4

mrstep Member since:
2009-07-18

All the time - it's totally useful for development. Say I'm exporting from a graphics app, and then need to copy to another directory - I can easily see which files have most recently been updates (both source and resources) and know that things are in the right state. It's useful for photos if you browse the directory containing them, documents, etc. Name is useful if you know the name, but by last-modified is incredibly good to have too.

And speaking of command line, I just needed to concatenate multiple .pvr graphics files into a single file, and the GUI tools I have don't want to do that. Pity the person who doesn't know how to cat 1.pvr 2.pvr ... > merged.pvr. Just sayin'.

Reply Score: 1

rcsteiner Member since:
2005-07-12


If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.

How about using the "apropos" command? Or man -k?

http://en.wikipedia.org/wiki/Apropos_%28Unix%29

Reply Score: 3

sorpigal Member since:
2005-11-02

If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.


Oh yeah? Try

man -k .

(don't forget the . at the end, it's important)

But given that you didn't know this I think this really only backs up the poor discoverability argument.

Reply Score: 2

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 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 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 Score: 3

RE: A bit optimistic and naive...
by Alfman on Fri 5th Aug 2011 18:13 UTC in reply to "A bit optimistic and naive..."
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 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 Score: 2

Comment by jollix
by jollix on Fri 5th Aug 2011 18:10 UTC
jollix
Member since:
2010-10-27

I am sure someone anywhere in the world finds the radio "faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible" than the television.
Sure the militars share this too.
It's way more faster saying "Mayday" or transmit "SOS" than sending a video of a sinking ship or whatever, but I personally have never used them (and expect it to keep going this way). So I keep enjoying my TV ;)

Edited 2011-08-05 18:13 UTC

Reply Score: 2

RE: Comment by jollix
by steogede2 on Fri 5th Aug 2011 22:53 UTC in reply to "Comment by jollix"
steogede2 Member since:
2007-08-17

I am sure someone anywhere in the world finds the radio "faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible" than the television.


Have you tried watching the telly whilst driving your car or jogging?

Reply Score: 3

RE: Comment by jollix
by Phloptical on Sat 6th Aug 2011 16:18 UTC in reply to "Comment by jollix"
Phloptical Member since:
2006-10-10

Why does it see that some comments arguing against CLI are modded down? Most are valid points of debate against a culture that is inevitably going the way of the AM radio because, face it...CLI is dying. Eventually all the dinosaurs that grew up banging away at keyboards for 2 minutes, just to begin a process that will last (at most) 30 seconds, will eventually retire/conform/die or simply go away.

Edited 2011-08-06 16:30 UTC

Reply Score: 2

RE[2]: Comment by jollix
by mrstep on Sat 6th Aug 2011 22:22 UTC in reply to "RE: Comment by jollix"
mrstep Member since:
2009-07-18

I'd guess that advocating a 'you only need a GUI' approach to people who actually need to do more with their computers is what's getting you modded down.

I happened to post this already above before seeing your comment, but as an example, I needed to generate multiple mipmap levels for a .pvr file the other night. The GUI tool outputs nicely dithered versions of those files, but doesn't give you multiple levels as an output option, and doesn't actually complete the 'chain' back up to the smallest size at all - the tool won't save the smallest sizes that are needed. There's a command line tool that will do those final sizes in a merged .pvr file. So I needed to merge the output from the GUI tool with the output from the other tool to get a complete .pvr with all mipmap levels.

Go GUI! Uh... no, not really. try 'cat 1.pvr 2.pvr 345.pvr > merged.pvr'. Done. The GUI tools don't do what I want in this case, and I wouldn't waste my time looking for a GUI app that will take a few files as drag-drop input to write out a merged file when I can do a command line hit in a second. And script it to make it part of my workflow if I need to do it repeatedly.

So it depends on what you're doing, but I can certainly guess why people disagree with you if you think one size really fits all. Not to mention that there are cases where the 30 second process that took 2 minutes to string together would take hours to do by hand or write in some other language.

Reply Score: 1

Powershell vs Bash
by Bill Shooter of Bul on Fri 5th Aug 2011 18:25 UTC
Bill Shooter of Bul
Member since:
2006-07-14

PowerShell the MS CLI scripting language/environment was sorta kinda developed to be easier to use than good ole bash. They have longer command names to make things easier, work with objects instead of text. All things that make sense.

... Except I don't like it. Maybe its because I've been using bash forever. Maybe because I think its because in trying to be easier to use, its lost its simplicity in use. Ie faster to learn but more complex in the data structures = frustration some how. I can't really explain it. Its like trying to explain why 1+1 is not always two. Maybe I'm in a funky vector space with an non positive definite metric.

Reply Score: 4

RE: Powershell vs Bash
by Vanders on Fri 5th Aug 2011 18:43 UTC in reply to "Powershell vs Bash"
Vanders Member since:
2005-07-06

One thing PowerShell has right is that it extends interprocess pipelining beyond simple text streams. If I had the time I'd love to take Bash, strip out some of the more arcane syntax and add the concept of structured data pipelining; imagine what you could do if you could get common commands to emit say, objects as JSON data and then manipulate them?

Reply Score: 2

RE[2]: Powershell vs Bash
by TemporalBeing on Fri 5th Aug 2011 20:21 UTC in reply to "RE: Powershell vs Bash"
TemporalBeing Member since:
2007-08-22

One thing PowerShell has right is that it extends interprocess pipelining beyond simple text streams. If I had the time I'd love to take Bash, strip out some of the more arcane syntax and add the concept of structured data pipelining; imagine what you could do if you could get common commands to emit say, objects as JSON data and then manipulate them?


I would actually argue that the non-use of simple text streams is exactly what is wrong with PowerShell.

While I've used Bash for quite a while, I've tried to pick up PowerShell (namely to start replacing Batch scripts) and find it far easier to just use WSH+JavaScript that to interact with the PowerShell.

As with much of Microsoft Technology, it's way too complex to actually be useful and efficient.

Reply Score: 2

RE[3]: Powershell vs Bash
by benjymouse on Sat 6th Aug 2011 17:55 UTC in reply to "RE[2]: Powershell vs Bash"
benjymouse Member since:
2011-08-06

I would actually argue that the non-use of simple text streams is exactly what is wrong with PowerShell.


Stream of objects can be a stream of strings - which is how "legacy" commands are integrated into PowerShell. You can work that way if you prefer.

However, the object-oriented streams add tremendous robustness, simplicity and readability to scripts and scripting. There are far fewer surprises than with *sh scripting.

While I've used Bash for quite a while, I've tried to pick up PowerShell (namely to start replacing Batch scripts) and find it far easier to just use WSH+JavaScript that to interact with the PowerShell.

As with much of Microsoft Technology, it's way too complex to actually be useful and efficient.


It is always hard to learn new skills. However, PowerShell is well worth it.

Reply Score: 1

RE[4]: Powershell vs Bash
by Bill Shooter of Bul on Sat 6th Aug 2011 18:04 UTC in reply to "RE[3]: Powershell vs Bash"
Bill Shooter of Bul Member since:
2006-07-14

It is always hard to learn new skills. However, PowerShell is well worth it.


If you spend a lot of time on Windows. I learned it just before I left the platform, and I was pretty frustrated that it didn't come standard on Vista RTM. At the time it was a great scripting language... that didn't exist on anyone's computers. Has that changed? Does windows 7 come with any version of the dot net framework and/or Silverlight?

Reply Score: 2

RE[5]: Powershell vs Bash
by _txf_ on Sat 6th Aug 2011 18:15 UTC in reply to "RE[4]: Powershell vs Bash"
_txf_ Member since:
2008-03-17

Has that changed? Does windows 7 come with any version of the dot net framework and/or Silverlight?


It comes with the runtimes. So to get powershell working you still need to download a buck load of stuff (at least on consumer versions of windows).

Reply Score: 2

RE[6]: Powershell vs Bash
by benjymouse on Sat 6th Aug 2011 18:24 UTC in reply to "RE[5]: Powershell vs Bash"
benjymouse Member since:
2011-08-06

It comes with the runtimes. So to get powershell working you still need to download a buck load of stuff (at least on consumer versions of windows).


No, PowerShell v2 is an integral part of Windows 7. You do not need to download anything. You do not need to turn anything on. In fact, you cannot turn it off :-)

Now, if you want to use certain modules, like SQL Server administration you may have to download a snapin or a module.

Edited 2011-08-06 18:28 UTC

Reply Score: 1

RE[5]: Powershell vs Bash
by benjymouse on Sat 6th Aug 2011 18:18 UTC in reply to "RE[4]: Powershell vs Bash"
benjymouse Member since:
2011-08-06

If you spend a lot of time on Windows.


Sort of agree there. PowerShell is a much better fit for Windows than other OSes, since Windows API is already almost exclusively object-oriented (handles, WMI, COM, .NET).

... that didn't exist on anyone's computers. Has that changed? Does windows 7 come with any version of the dot net framework and/or Silverlight?


With Windows 7 PowerShell is an operating system component since several tools which come with the OS are based on it (e.g. troubleshooting scripts like the one that runs when you click "troubleshoot problems" on a faulty network connection). Several new server products from MS have advanced functionality which can only be reached through PowerShell.

PowerShell is a system component since Vista SP1 - although it had to be "turned on". Since Windows 7 / Server 2008 it is a mandatory component.

Edited 2011-08-06 18:26 UTC

Reply Score: 1

RE[2]: Powershell vs Bash
by linux-it on Mon 8th Aug 2011 17:28 UTC in reply to "RE: Powershell vs Bash"
linux-it Member since:
2006-07-13

now, the simple text streams don't eat much memory, makes interrupting things when you find what you need etc.

Like looking in some database thing and grep out of it. It's faster with bash, because it uses small pipes instead of buffering the whole stuff, even if the text is already there.It will presented at the end.

The biggest drawback is that large datasets will eat up all memory.


Powershell in it's best for is a small subset of what scripting can do under unix type of operating systems.

Reply Score: 2

RE[3]: Powershell vs Bash
by benjymouse on Tue 9th Aug 2011 20:08 UTC in reply to "RE[2]: Powershell vs Bash"
benjymouse Member since:
2011-08-06

now, the simple text streams don't eat much memory, makes interrupting things when you find what you need etc.

Like looking in some database thing and grep out of it. It's faster with bash, because it uses small pipes instead of buffering the whole stuff, even if the text is already there.It will presented at the end.


Ahem! PowerShell objects are *streamed* as well; they are pushed through the pipeline one-by-one. Because it is all in-process what is pushed through the pipeline is actually only an in-memory pointer. That is arguably both *faster* and more memory-efficient than constantly serializing to/from strings.

I don't know where you have gotten the idea that PowerShell would buffer everything until the end?

The biggest drawback is that large datasets will eat up all memory.

Once an object has been passed on through the pipeline it is eligible for garbage collection. Large datasets will not need to be allocated all at once.


Powershell in it's best for is a small subset of what scripting can do under unix type of operating systems.

PowerShell is much more capable than unix/linux *sh style shell scripting, more consistent, more robust and more secure.

Reply Score: 1

RE: Powershell vs Bash
by whartung on Fri 5th Aug 2011 19:34 UTC in reply to "Powershell vs Bash"
whartung Member since:
2005-07-06

I think PowerShell may be a better SCRIPTING language, but I don't know if it's a better COMMAND LINE language. The terseness and expressiveness of the generic SH command line is very powerful. The additional lengths and complexity of the the elements in PowerShell warrant more an edit/run lifecycle than simply a type it and go and creating simple one offs that SH promotes.

Reply Score: 2

RE[2]: Powershell vs Bash
by benjymouse on Sat 6th Aug 2011 17:50 UTC in reply to "RE: Powershell vs Bash"
benjymouse Member since:
2011-08-06

The terseness and expressiveness of the generic SH command line is very powerful. The additional lengths and complexity of the the elements in PowerShell warrant more


I am curious as to why you find PowerShell have "additional lengths". I do a lot of scripting in PowerShell and I find that it is almost *always* shorter and more concise than the bash equivalent. Do you have any examples?

Also, I find PowerShell is *a lot* more consistent (naming conventions, parsing rules, parameter passing) with fewer specialized single-purpose features. Don't be fooled by PowerShell examples which (for instructive purposes) use the long-name versions of common commands. For the common commands there's often a short alias (which are a true aliases rather then bash "macro" aliases).

Reply Score: 1

RE: Powershell vs Bash
by Flatland_Spider on Sat 6th Aug 2011 00:26 UTC in reply to "Powershell vs Bash"
Flatland_Spider Member since:
2006-09-01

I like the that's it's object oriented, which opens up lots of cool things, but I find it too wordy and obtuse as well.

I don't think they went for simplicity with Powershell. I think they did a 180 from the DOS like cmd.exe, and created an alien shell with a bunch of complex tools. Powershell is Swiss Army knives and Erector set pieces, and the Unix shell is kitchen utensils and Legos.

Reply Score: 2

Different domains ...
by MacTO on Fri 5th Aug 2011 18:40 UTC
MacTO
Member since:
2006-09-21

The CLI is great in some cases. The GUI is better in others.

The most basic scenario: if I'm doing something infrequently, I want a GUI. Discovery and recognition mean that I will spend a lot less time looking things up then applying them. On the other hand, if I do something a lot, a CLI will allows me to cut to the chase and just do it (i.e. no digging through menus and dialog boxes). CLIs also provide much better facilities for automation.

The task matters too. If I'm doing something 'linguistic' (e.g. word processing, programming, file management), using a GUI means that the brain is constantly context switching between linguistic and visual/spatial processing. On the other hand, trying to express something spatial in linguistic terms creates a similar problem. If you ever tried to use POV-Ray for 3-D modelling you'll know what I mean.

Finally, there's the person involved. Some people are more linguistic, while others are more spatial/visual. Some people have excellent recall (great for CLIs), while others have a wonderful ability to recognize visual cues (fantastic for GUIs). Neither skill set is better overall, but each skill set is better in a certain domain.

Reply Score: 5

The VMS DCL command Line
by shotsman on Fri 5th Aug 2011 20:15 UTC
shotsman
Member since:
2005-07-22

Now that is a complete work.
If in doubt type help.
Totally hierarchial
Plenty of examples in the help

What more could you need?

Answer.... Nowt.

Unix Shell? Pah
Dos ? You must be joking.

In VMS DCL you could build a complete system installer.
Then the Files system could handle OOTB indexed Sequential files.
All from 1977. Years aherad of its time methinks.

Yeah, I spent 20years working on VMS for DEC. nothing I have ever come upon since is anywhere near as powerful as DCL.

Reply Score: 3

RE: The VMS DCL command Line
by Flatland_Spider on Fri 5th Aug 2011 23:51 UTC in reply to "The VMS DCL command Line"
Flatland_Spider Member since:
2006-09-01

VMS has always been the one OS I haven't been able to get my hands on that I've really wanted to.

I've heard some really good stuff about it, but I've never been able to experience it first hand.

It's cool that you hang out here.

Reply Score: 1

RE[2]: The VMS DCL command Line
by helf on Sat 6th Aug 2011 12:50 UTC in reply to "RE: The VMS DCL command Line"
helf Member since:
2005-07-06

If you want to try out VMS, then you can create an account on the Deathrow Cluster - http://deathrow.vistech.net/

Reply Score: 3

the cart before the horse.
by unclefester on Fri 5th Aug 2011 22:55 UTC
unclefester
Member since:
2007-01-13

I recently read a comment from a legendary Mongolian horse trainer:

In Mongolia we teach our children to think like a horse. A horse can never learn to think like a human.


In the Western context we should teach people to understand how computers function (file hierarchy, commands etc) not try and not waste enormous efforts on making computers understand us.

Back mid 80s when I was using DOS I was probably much faster using the CLI and function keys than I am now on a Gnome GUI.

Reply Score: 7

AIX
by qroon on Sat 6th Aug 2011 00:42 UTC
qroon
Member since:
2005-10-21

I love the commands in AIX. Mostly prefixed with:

mk
ch
ls
rm

i.e. mklv, chuser, lsgroup, rmvg

Reply Score: 3

.
by Icaria on Sat 6th Aug 2011 12:58 UTC
Icaria
Member since:
2010-06-19

Depends upon the task as much as it depends upon the user as much as it depends upon the tools in-question.

More interactive, trial-and-error oriented activities will obviously benefit from a GUI. Users unfamiliar with the tools will benefit from both graphical toolkits and a common syntax/set of utilities, from which they can draw upon the domain-general knowledge a user should have.

The real weak link (ignoring for a moment the existence of the computer illiterate) is the tools, which tend to be horribly inconsistent, regardless of whether they're graphical, or terminal-based.


I'm reasonably mixed in my usage patterns. Without even thinking about it, I often find myself using both a graphical file manager and BASH (for the purposes of file management) at the same time. I don't generally feel that one offers a benefit over the other but then I practically use my file manager like I would an interactive CLI tool, typing to navigate and employing keyboard shortcuts to invoke file operations.

Reply Score: 1

totally unnecessary post !
by kovacm on Sat 6th Aug 2011 18:35 UTC
kovacm
Member since:
2010-12-16

Ramsay goes on to describe scenarios, such as building a music playlist ("create playlist "country plus katy" from last 11") wherein a simple typed description would me much faster, and in fact much easier (even for a n00b) than all the clicking and dragging and menus that it would require using a GUI.


try QuickSilver for Mac OS X and then come again to comment ;) !!!

Reply Score: 1

Comment by wayne1932
by wayne1932 on Sun 7th Aug 2011 13:17 UTC
wayne1932
Member since:
2005-07-06

There is a definite problem for those of us who are keyboard challenged. I can type at 50/60 wpm, but accuracy is in the dump. I have used the CLI, but by the time I have checked it for accuracy, (is that one or two spaces, is that a 0 or O, or a 1 or l?, or a typo) I feel that longing for a GUI which just asks me what I want.

Reply Score: 1

...
by Tuishimi on Mon 8th Aug 2011 19:49 UTC
Tuishimi
Member since:
2005-07-06

"Computer."
Picks up mouse, raises in front of face.
"Computer!"

Reply Score: 2