Command Line Interfaces Ought to be Disallowed
-
Ah, then I suppose I must instead be an Übermensch. Perhaps I should start acting like real men and lower my standards.
-
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 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)
-
:downvote: :downvote: :downvote: :downvote: 0) GUIs are difficult to automate.
That's exactly why I like them. And some programs don't make sense with a GUI version, because they are utilities solely for other programs to use, not human beings (in some cases a separate executable is preferable to linking to a library, like when it's used by a program you don't have source access to).
-
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)
In the past the command line was more powerful. Never really understood why but it is still that way in windows. There are things you can do from the command line that windows doesn't have a gui. Although I suppose the gap is getting smaller and smaller. One day even programming won't be typing. It'll all be drag and drop, by finger, probably. :-D And there is always the automation part. I don't really want to write a program to change a registry setting each time I boot. Much easier to script it out, but then I'm not your normal user.
-
In the past the command line was more powerful. Never really understood why but it is still that way in windows. There are things you can do from the command line that windows doesn't have a gui. Although I suppose the gap is getting smaller and smaller. One day even programming won't be typing. It'll all be drag and drop, by finger, probably. :-D And there is always the automation part. I don't really want to write a program to change a registry setting each time I boot. Much easier to script it out, but then I'm not your normal user.
Raeldin wrote:
There are things you can do from the command line that windows doesn't have a gui.
Yes and that can be a problem although not so much on Windows. Up until about 18 months ago there were major supposedly 'desktop' versions of Linux supposedly targetted at the ordinary user where it was impossible to connect to a network much less the internet without hacking text files from the command line, not because they hadn't put in the time, not because they didn't know how to do it, not because it was an oversite ( most desktop toolbars had a network connection status widget just nowhere to enter an ip address or tick a box for DHCP ) but basically because connecting to a network was considered by the developers to be too much dangerous power to give to the kind of people who use GUIs. 'Don't let them loose with that they'll only screw it up'. This is the sort of attitude that's meant Linux has failed to make a serious impact on the desktop despite all the open goals left by Microsoft. I've never suggested that the command line should be taken away from anyone who wants to use it just that proper user interfaces that fully expose the functionality of the software should be normal and expected. The best way I can see of achieving that would be a kind of sane form of XAML that generates both at once. I haven't written it yet but I know how it should work should anyone get the urge. :-D
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
:downvote: :downvote: :downvote: :downvote: 0) GUIs are difficult to automate.
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".
-
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.