3 ms·

Personally I loathe having to use any sort of GUI because in general its slow and I cannot as easily automate tasks to customize my workflow. There's a reason t

Personally I loathe having to use any sort of GUI because in general its slow and I cannot as easily automate tasks to customize my workflow. There's a reason there are more command line tools and GUI tools, the command line tools can be easier to build. Compound that by the fact that a lot of engineers lack a certain design sense to create a beautiful easy to use GUI but they can build powerful command line tools. I respect the people who take the time to put together a GUI that make the end users life easier, it undoubtably takes a lot if not more work than the original application to get right.

superuser2 12y ago
Hence on top of command line applications. The power and flexibility are still there for people who want them, but so are the GUIs.
- sehrope 12y ago
  > Hence on top of command line applications. The power and flexibility are still there for people who want them, but so are the GUIs. You don't want the GUI to be "on top of" the command line. A CLI makes for a terrible piece of code to integrate with! What you really want is for both of them to share a common library. The CLI should be a client of the library just like the GUI. Usually the CLI and the library will be developed in tandem (so you have an endpoint to invoke a new library feature) but keeping them separate is a good idea.
  - twic 12y ago
    A typical CLI might make a terrible piece of code to integrate with. I wonder if you can design CLIs that are better to integrate with, though. To some extent, this is what Git's 'plumbing' layer tries to be, although i don't know how successful it is. One advantage of building on top of the CLI rather than via a library is that it enforces the rule that any functionality available in the GUI is also available in the CLI. It also means that any functionality added to the CLI is also immediately available to the GUI. With the library approach, it's easier for one to get ahead of the other. Mercurial has an interesting take on this - the command server: http://mercurial.selenic.com/wiki/CommandServer http://mercurial.selenic.com/wiki/CommandServer This lets a process spawn a sort of daemon version of Mercurial, with which it can communicate via its standard input and output. Communication is a machine-friendly framing protocol which allows the parent to execute Mercurial commands. These are the same commands as you would use on the command line (interpreted by the same dispatcher, i believe, so really exactly the same). So, it's good code to integrate with, but exactly as powerful as the CLI. The one real let-down is that the output is, AFAIK, the same as Mercurial's interactive output, which means the parent has to parse it with various command-specific regexps. If you were following this approach from the beginning, you would probably structure your CLI so that commands emit output in some structured form (eg a tree of named, typed values, or a table of named, typed columns), which is then rendered to the console somehow. You could then return a machine-friendly serialisation of that in command server mode.
trollingineer 12y ago
Oh please. Spare me from your GUI-MASTER-RACE bullshit. I can review a commit diff way faster in Tower than you ever could on the command-line even with your "customizations." Also - "automate tasks and customize" your workflow to actually not do your job properly. Good job bro.
chipotle_coyote 12y ago
Personally I loathe having to use any sort of GUI because in general its slow and I cannot as easily automate tasks to customize my workflow. There's a lot of research out there that provides a lot of evidence that GUIs in general aren't slow, assuming they're well-designed; they feel slower to people used to CLIs and keyboard-driven interfaces, but when you actually measure objectively with a stopwatch the results tend to favor GUIs. I think it's the second part of your statement about automating tasks where CLIs really have the advantage. For GUI programs to be automated they have to provide a scripting API much more complicated than just an input and output stream -- and then, of course, you need a scripting language to bind them. OS X's Automator is a really great glimpse of how that could be done in an entirely GUI fashion, but it also shows the limitations of such an approach -- most of which aren't in Automator itself, but the very fact that applications need to be written to support it. (Of course, some of the built-in actions let you run AppleScript or any shell language programs.)

superuser2 12y ago

Hence on top of command line applications. The power and flexibility are still there for people who want them, but so are the GUIs.

sehrope 12y ago
> Hence on top of command line applications. The power and flexibility are still there for people who want them, but so are the GUIs. You don't want the GUI to be "on top of" the command line. A CLI makes for a terrible piece of code to integrate with! What you really want is for both of them to share a common library. The CLI should be a client of the library just like the GUI. Usually the CLI and the library will be developed in tandem (so you have an endpoint to invoke a new library feature) but keeping them separate is a good idea.
- twic 12y ago
  A typical CLI might make a terrible piece of code to integrate with. I wonder if you can design CLIs that are better to integrate with, though. To some extent, this is what Git's 'plumbing' layer tries to be, although i don't know how successful it is. One advantage of building on top of the CLI rather than via a library is that it enforces the rule that any functionality available in the GUI is also available in the CLI. It also means that any functionality added to the CLI is also immediately available to the GUI. With the library approach, it's easier for one to get ahead of the other. Mercurial has an interesting take on this - the command server: http://mercurial.selenic.com/wiki/CommandServer http://mercurial.selenic.com/wiki/CommandServer This lets a process spawn a sort of daemon version of Mercurial, with which it can communicate via its standard input and output. Communication is a machine-friendly framing protocol which allows the parent to execute Mercurial commands. These are the same commands as you would use on the command line (interpreted by the same dispatcher, i believe, so really exactly the same). So, it's good code to integrate with, but exactly as powerful as the CLI. The one real let-down is that the output is, AFAIK, the same as Mercurial's interactive output, which means the parent has to parse it with various command-specific regexps. If you were following this approach from the beginning, you would probably structure your CLI so that commands emit output in some structured form (eg a tree of named, typed values, or a table of named, typed columns), which is then rendered to the console somehow. You could then return a machine-friendly serialisation of that in command server mode.

trollingineer 12y ago

Oh please. Spare me from your GUI-MASTER-RACE bullshit. I can review a commit diff way faster in Tower than you ever could on the command-line even with your "customizations." Also - "automate tasks and customize" your workflow to actually not do your job properly. Good job bro.

chipotle_coyote 12y ago

Personally I loathe having to use any sort of GUI because in general its slow and I cannot as easily automate tasks to customize my workflow. There's a lot of research out there that provides a lot of evidence that GUIs in general aren't slow, assuming they're well-designed; they feel slower to people used to CLIs and keyboard-driven interfaces, but when you actually measure objectively with a stopwatch the results tend to favor GUIs. I think it's the second part of your statement about automating tasks where CLIs really have the advantage. For GUI programs to be automated they have to provide a scripting API much more complicated than just an input and output stream -- and then, of course, you need a scripting language to bind them. OS X's Automator is a really great glimpse of how that could be done in an entirely GUI fashion, but it also shows the limitations of such an approach -- most of which aren't in Automator itself, but the very fact that applications need to be written to support it. (Of course, some of the built-in actions let you run AppleScript or any shell language programs.)