Command Line Interfaces Ought to be Disallowed
-
Consider the situation of searching for a simple file. Suppose you have a file where you know the name contains "ClientData" and you know it's an XML file. But you're not sure where it's saved or where all it's saved, or even better you want to find some Browser cookies. Regardless of how much ram you have, it's still a lot quicker to open a command line, and type dir /s ClientData.xml Or if you had some wild cards because you weren't exactly sure of the namming dir /s *Client*.xml Then it is to do a windows file search using the GUI.
Right. File operations are a good example. Many times one needs to delete a bunch of files and deleting with wildcards is way easier than by pointing and clicking -- although sorting in the Explorer can help you select a group of files in some cases. On the other hand, some times you need to delete a number of files that don't have similar names and don't lend themselves to wildcards. In such cases the GUI may be superior -- I certainly didn't like having to type in each file name. At least nowadays I can use the mouse to copy/paste the file names. Yet there are many file operations that you can do with (DOS) commands that you can't do with Explorer. Piping comes to mind --- with TYPE or FIND or SORT Also combining files with COPY I don't see how you do those with Explorer. And I don't see why anyone would consider these things "advanced"; they're pretty basic -- been there since the 70s. I write a lot of console applications, many I could write in WinForms, but there'd be no reason to. Simple is better. P.S. What's the Visual Studio equivalent of this:
csc /recurse:*.cs -
All other things being equal. If the GUI takes 2 minutes and the command prompt takes 2 minutes, I'm going to prefer the GUI (unless I have to do some sort of automation or what have you).
(DOS boxes don't take two minutes to open.) And how many different GUIs will you have to load to do what I can do in one DOS box? SSMS for SQL VS for code compilation Some source control GUI for ... source control Explorer for file operations
-
(DOS boxes don't take two minutes to open.) And how many different GUIs will you have to load to do what I can do in one DOS box? SSMS for SQL VS for code compilation Some source control GUI for ... source control Explorer for file operations
Yep, I kiss those 10 seconds goodbye each and every time I restart my computer. :((
-
That assumes I know the command line parameters. Or that "*" means "any number of other characters". I'd rather use a GUI that allows me to type in "Client" and select "Any file names containing this word" and select "specify extension" with a value of "xml", and then check "search subdirectories recursively". And maybe there would be a "more" button in case I want to do more advanced tasks, like use regular expressions to search based on patterns. The learning curve is part of the equation for ease of use. Another nice feature of GUIs is that they can easily present you with actions you've taken (e.g., recent searches) and allow you to modify them. Depending on the command line, you can bring up previously used commands, but not as quickly (e.g., you have to press "Up" to scan through them one by one, and there is no way to filter based on application). A picture is worth a thousand words, and a GUI is worth a thousand commands.
AspDotNetDev wrote:
a GUI is worth a thousand commands
Bullshit. There's (generally) a one-to-one correspondence. :-D
-
AspDotNetDev wrote:
a GUI is worth a thousand commands
Bullshit. There's (generally) a one-to-one correspondence. :-D
Per pixel. :-\
-
Per pixel. :-\
Sure. My DOS box uses just as many pixels as your GUI. Maybe more, I maximize.
-
I disagree but only because I think the command line interface should be auto generated from the same description that generates the GUI, ensuring complete consistency and complete access to all features. The fundamental problem of command line interfaces is lack of discoverability. I can't see what my options are which also fails to prompt my memory from the last time I worked it out by trawling the docs so there's a lack of learnability to mint a new word aswell. When you add to this inconsistency because command line options are just made up to no standard and often without reference to one another you have the nightmare that is Linux/Unix/&c. However once you're an expert user who knows exactly what they want to do then being restricted to only using the functionality from one program at a time because you have open the big colourful UI and find the right menu option or widget to poke is really annoying. Especially when what you want to be able to do is tie together your mail client, favourite encryption engine and some else's database in one command and have last years emails archived with encryption to a cloud server. I've seen many Linux gurus do that sort of thing with a single command line and comment quite accurately that it would have taken half an hour on Windows if it was possible at all. Both camps are of course entirely right about the advantages of their way of doing things, entirely right about the disadvantages of doing things the other way and entirely miss the point that it shouldn't have to be an either/or choice.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
I disagree but only because I think the command line interface should be auto generated from the same description that generates the GUI, ensuring complete consistency and complete access to all features.
I worked for a company that had their own SCM product that was originally command line only (originally derived from CMS on VAX/VMS circa 1978). A UI was added later, and really what it did was present edit controls, radio buttons and check boxes, and in fact composed a command line behind the scenes and executed it in an invisible command window, screen scraping the result(s) and reporting success/failure as appropriate. Life imitates art, I would say.
-- Harvey
-
That assumes I know the command line parameters. Or that "*" means "any number of other characters". I'd rather use a GUI that allows me to type in "Client" and select "Any file names containing this word" and select "specify extension" with a value of "xml", and then check "search subdirectories recursively". And maybe there would be a "more" button in case I want to do more advanced tasks, like use regular expressions to search based on patterns. The learning curve is part of the equation for ease of use. Another nice feature of GUIs is that they can easily present you with actions you've taken (e.g., recent searches) and allow you to modify them. Depending on the command line, you can bring up previously used commands, but not as quickly (e.g., you have to press "Up" to scan through them one by one, and there is no way to filter based on application). A picture is worth a thousand words, and a GUI is worth a thousand commands.
AspDotNetDev wrote:
a GUI is worth a thousand commands.
*BZZZZT!!* Wrong wrong wrong!! The one great big huge enormous frustrations with GUIs is that they can't be easily automated, unless that is a goal of the specific GUI. In fact the opposite is true, or to say it a different way, a command line is worth 10000 mouse clicks.
-- Harvey
-
Consider the situation of searching for a simple file. Suppose you have a file where you know the name contains "ClientData" and you know it's an XML file. But you're not sure where it's saved or where all it's saved, or even better you want to find some Browser cookies. Regardless of how much ram you have, it's still a lot quicker to open a command line, and type dir /s ClientData.xml Or if you had some wild cards because you weren't exactly sure of the namming dir /s *Client*.xml Then it is to do a windows file search using the GUI.
CdnSecurityEngineer wrote:
...it's still a lot quicker to open a command line, and type dir /s ClientData.xml
Or if you had some wild cards because you weren't exactly sure of the namming
dir /s *Client*.xml
Then it is to do a windows file search using the GUI.I don't argue much with this but I feel that Microsoft took a step backwards in going from Windows File Manager to Windows Explorer. If interested, you can get WinFile from here[^].
-- Harvey
-
Well, unless there is a corresponding UI. From what I've read, it seems like Git is mostly used from the command line. Or maybe I'm wrong. Maybe people just prefer to use the command line versions. Maybe that's because the user interfaces are not very mature or are difficult to use?
I use GIT with GIT Extensions[^] both at home and have introduced it to my work place. I find it works well in the very small team I am part of(me and one other at present) - the UI seems fairly good to me and has saved me when I have had to merge changes due to different versions being worked on:)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
AspDotNetDev wrote:
a GUI is worth a thousand commands.
*BZZZZT!!* Wrong wrong wrong!! The one great big huge enormous frustrations with GUIs is that they can't be easily automated, unless that is a goal of the specific GUI. In fact the opposite is true, or to say it a different way, a command line is worth 10000 mouse clicks.
-- Harvey
Perhaps GUIs are worth the first thousand commands, and command lines are worth the next 10,000 mouse clicks (which, thanks to command line automation, will occur over 5 seconds).
-
I use GIT with GIT Extensions[^] both at home and have introduced it to my work place. I find it works well in the very small team I am part of(me and one other at present) - the UI seems fairly good to me and has saved me when I have had to merge changes due to different versions being worked on:)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Wow, even comes with YouTube videos to show how to use it. Sweet!
-
Well, unless there is a corresponding UI. From what I've read, it seems like Git is mostly used from the command line. Or maybe I'm wrong. Maybe people just prefer to use the command line versions. Maybe that's because the user interfaces are not very mature or are difficult to use?
-
Looks promising. I like SmartSVN, and this looks similar. Maybe people just use command lines because they don't want to pay for a GUI?