Command Line Interfaces Ought to be Disallowed
-
Command lines should be for advanced scenarios. I should be able to use an application from a GUI and then use a command line if I actually need to automate anything or reduce the memory footprint (my computer has 16GB of RAM, so I'm not too concerned with my footprint).
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.
-
Yeah, I'm sure I'll be using PowerShell if I ever get my company to put our websites on Azure. But that's for advanced scenarios... for basic usage, GUIs are superior to command lines.
AspDotNetDev wrote:
for basic usage, GUIs are superior to command lines.
No, they're not. But then I was raised on a real operating system, with a terminus, without even copy/paste.
-
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?
AspDotNetDev wrote:
Well, unless there is a corresponding UI.
Wrong. Just as claiming that all applications should be programmed in language X is wrong.
AspDotNetDev wrote:
From what I've read, it seems like Git is mostly used from the command line.
I use a GUI exclusively for that. So obviously not an appropriate comparison for your general assertion.
AspDotNetDev wrote:
Maybe people just prefer to use the command line version
I prefer to create applications that do what they need to do. Applications that I produce are servers. There is no need to create a GUI to modify values, if modification is needed at all, it is only when the server is installed. GUIs always exist but as client user interacting via some mechanism as a web application. Other than that applications I create exist to facilitate development often in the build process or in tasks suitable for scheduling. I actually had a task at one time to add a management GUI to a server. It languished for 3 years without ever being prioritized enough to actually even start on it much less finish it. In summary none of the applications I create are suited to providing GUI user interfaces in terms of cost effectiveness.
-
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.
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.
-
Yeah, I'm sure I'll be using PowerShell if I ever get my company to put our websites on Azure. But that's for advanced scenarios... for basic usage, GUIs are superior to command lines.
If it takes 2 minutes to start a GUI (i.e.: The ConfigMan console in System Center Configuration Manager), over 2 seconds to launch a CMD prompt and a generous 30 seconds to type a command, I fail to see how a GUI is superior.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
AspDotNetDev wrote:
Well, unless there is a corresponding UI.
Wrong. Just as claiming that all applications should be programmed in language X is wrong.
AspDotNetDev wrote:
From what I've read, it seems like Git is mostly used from the command line.
I use a GUI exclusively for that. So obviously not an appropriate comparison for your general assertion.
AspDotNetDev wrote:
Maybe people just prefer to use the command line version
I prefer to create applications that do what they need to do. Applications that I produce are servers. There is no need to create a GUI to modify values, if modification is needed at all, it is only when the server is installed. GUIs always exist but as client user interacting via some mechanism as a web application. Other than that applications I create exist to facilitate development often in the build process or in tasks suitable for scheduling. I actually had a task at one time to add a management GUI to a server. It languished for 3 years without ever being prioritized enough to actually even start on it much less finish it. In summary none of the applications I create are suited to providing GUI user interfaces in terms of cost effectiveness.
Indeed, there are some applications that are only appropriate as a command line. There are even some cases where it's not appropriate to build a GUI or command line (i.e., the application just runs and does what it does, such as an app you create yourself to do something only once). For something like Git (and I'd say most applications that have human users), it is desirable at least for the user to have a GUI. Whether or not that's cost effective is another story. Also, there is a question of what is an "app". Something like an API/service/component isn't really an app, so it doesn't really have the same requirements. Some examples include the Facebook API, the Google location REST web services, and file zipping command line tool in WinZip. Sure, there are the Facebook application, the many Google Map components, and the WinZip client application built on top of those, but the underlying aspects are not themselves apps and so don't require a GUI.
-
If it takes 2 minutes to start a GUI (i.e.: The ConfigMan console in System Center Configuration Manager), over 2 seconds to launch a CMD prompt and a generous 30 seconds to type a command, I fail to see how a GUI is superior.
A guide to posting questions on CodeProject[^]
Dave KreskowiakAll 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).
-
:downvote: Heck no. Sure, having both is usually preferred, but some tasks just don't lend themselves to a GUI. While an IDE makes sense, would you want a GUI for a compiler/make/build utility? What benefit would a GUI give to a Ping utility? Or a sort utility? Would you merely wind up with a text app in a window? What's gained by that? Likwise, some tasks aren't suited to a command/textual interface -- image editing comes to mind. Ideally an application provides an API and any number of clients/interfaces can be produced. Not that I generally follow that advice. :sigh: Use the right tool for the right job.
PIEBALDconsult wrote:
While an IDE makes sense, would you want a GUI for a compiler/make/build utility?
If I have an IDE GUI, why would I want one for a compiler/etc? Though if I didn't have an IDE GUI, a GUI for the compiler/etc would be useful (at first, for learning, anyway). You could have dialogs to select files, checkboxes to toggle optimization, and so on. You could also have validation to prevent errors/message boxes to correct errors/config to remember previous configs (which command lines could do via config files, but then you've go to learn another file format when the GUI could do it for you).
PIEBALDconsult wrote:
Likwise, some tasks aren't suited to a command/textual interface
PIEBALDconsult wrote:
Use the right tool for the right job
I know I have been speaking in absolute terms ("ought to be disallowed", "ought to be required", and so on). I usually mean "when appropriate, which is most of the time, and in particular with Git."
-
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!