Command Line Interfaces Ought to be Disallowed
-
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?
-
Then provide a command line in addition to the GUI. But the GUI should be required. I suppose I should have titled this "GUIs Ought to Be Required".
: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.
-
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?
Wow. Considering Windows Server can be installed wihtout a GUI at all and current/future offerings are being managed more and more from the command line, it seems you're going in the wrong direction!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
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:
lack of discoverability
Same with Office and the Ribbon. X|
-
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?
Your statement that command line interfaces should be disallowed shows that you're either very new to the computing industry or very ignorant. User interfaces are slow, memory hogs, and if you don't really need them then why use them? Consider a server sitting on a rack somewhere, what reason would I ever have to hook a keyboard and monitor up to that? If I can configure everything through the command line and manage the server from the command line, I can save memory which can be used for servicing more requests and therefore processing power. Having been a user & then an engineer whom grew up with Windows 3.1 and later. I really missed out on the Windows Dos world. However even in Windows I still do 80% of everything I need from the command line. Sometimes I even surf the net from the command line! Why, 1: It's faster 2: Cuts down on all the garbage. I might write code (In Windows in Visual Studio). However I do all the compiling and building of the code from the cmd line. I only really use the GUI (IDE) in the sense when I actually need to really debug something, then again I hope I've written my code well enough to spit out meaningful error messages via logging. I've seen some pretty disastrous GUI's so next are you going to say only Good looking GUI's should be allowed? And if so, by who's standard are you going to judge that. I am sorry that you're having difficulty with a command line client. I love the command line it lets me automate tasks, where I find things with the command line difficult or repetitive I write a batch file to make my life easier. I would suggest to you that you could actually improve your productivity if you learned to embrace the command line. I am not even going to get into how wonderful the command line is in Unix. That just goes without saying.
-
Your statement that command line interfaces should be disallowed shows that you're either very new to the computing industry or very ignorant. User interfaces are slow, memory hogs, and if you don't really need them then why use them? Consider a server sitting on a rack somewhere, what reason would I ever have to hook a keyboard and monitor up to that? If I can configure everything through the command line and manage the server from the command line, I can save memory which can be used for servicing more requests and therefore processing power. Having been a user & then an engineer whom grew up with Windows 3.1 and later. I really missed out on the Windows Dos world. However even in Windows I still do 80% of everything I need from the command line. Sometimes I even surf the net from the command line! Why, 1: It's faster 2: Cuts down on all the garbage. I might write code (In Windows in Visual Studio). However I do all the compiling and building of the code from the cmd line. I only really use the GUI (IDE) in the sense when I actually need to really debug something, then again I hope I've written my code well enough to spit out meaningful error messages via logging. I've seen some pretty disastrous GUI's so next are you going to say only Good looking GUI's should be allowed? And if so, by who's standard are you going to judge that. I am sorry that you're having difficulty with a command line client. I love the command line it lets me automate tasks, where I find things with the command line difficult or repetitive I write a batch file to make my life easier. I would suggest to you that you could actually improve your productivity if you learned to embrace the command line. I am not even going to get into how wonderful the command line is in Unix. That just goes without saying.
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).
-
Wow. Considering Windows Server can be installed wihtout a GUI at all and current/future offerings are being managed more and more from the command line, it seems you're going in the wrong direction!
A guide to posting questions on CodeProject[^]
Dave KreskowiakYeah, 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.
-
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?
-
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