10 ms·

The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. I

by arrel 12y ago

The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. I switched to Tower for git a couple years ago, and seeing people struggle with diffs and rebasing on the command line makes me sad. This software may be version one and still have some kinks to work out, but I love it anyway. Nice work!

michaelmior 12y ago
I've never used Tower, but I haven't found diffs and rebasing on the command line to really cause me much trouble. I will agree that there is a segment of users who find such tools useful. I think part of the problem is that the segment of people who want GUI tools and the segment of people who build the underlying tools rarely overlap.
Osmium 12y ago
> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. I can't tell you how much I agree with this. Far too little engineering effort is spent on nice GUIs, especially for 'niche' applications (I'm talking the sciences here in particular), because the GUI doesn't add any functionality. It's true, but it sure as hell adds productivity. In regards to homebrew specifically though, I think the 'brew' command line app is actually one of the better ones and is actually pretty easy to use.
- aroch 12y ago
  >I'm talking the sciences here in particular Heh, tell me about it. There are better programs out there but we still use some written 20 years ago because they have a UI.
  - jwarren 12y ago
    This is startlingly true. The more I dive into development and open-source solutions, the more worrying this becomes. Edit: to maybe relieve the concerns of downvoters: I find it worrying because there are lots of generally productive and intelligent people who will avoid command line tools as much as possible. These are some very good programmers. This means that tools as simple as Grunt are deemed to be "too much fuss." I'm a big user and supporter of OSS, and I try and promote it as much as possible within my colleagues and peer group. I've had some success, but that's really another story for another time.
    - aroch 12y ago
      I was "volunteered" to maintain some old scripts that we use in the lab, some were written in Algol. The older the lab/institution the more worryingly old software is required by the researchers (Don't even ask about centrifuges that should have been retired almost a trillion revs ago).
pjmlp 12y ago
I feel the same way. Amiga and environments like Smalltalk and Oberon spoiled me for GUIs. I do master the CLI across multiple OSs, but only use them when I really need to.
ihuman 12y ago
Is homebrew that confusing though? I thought it was much simpler compared to other CLIs. Primarily, all you do is search, install, and uninstall.
- TillE 12y ago
  And update/upgrade, and the occasional cleanup. It really is extremely simple, and I don't know why anyone would be using Homebrew if they're not already comfortable with the command line.
  - GuiA 12y ago
    The modern programming movements, especially web development, have created many developers who can do (for example) some HTML, some CSS, a little bit of {Rails | Django | PHP}, a little bit of {Angular | JQuery | Ember.js }, etc. but are very uncomfortable with concepts/tools that a lot of hackers take for granted (using a command line being one example). Not saying it's a good thing or a bad thing, just how it is (especially with things like programming bootcamps and associate degrees focused on quick web development). Some of us have been swimming in Linux and obscure hacker culture for decades, and we forget that maybe one doesn't need the huge entire body of knowledge we have to be productive employees in a certain capacity?
    - malvosenior 12y ago
      It's a bad thing.
    - hippee-lee 12y ago
      > Not saying it's a good thing or a bad thing The tools we use are neither good nor bad. How well we use them, what we use them for and how we teach others to use them are what makes the good or bad. I love the way you make this conversation good with a pragmatic point of view and an opinionated but reasonable voice. Thank you.
- jwarren 12y ago
  IMO it has a really nice interface for a CLI. Lots of sensible colour coding and some of the clearest instructions/error messages I've come across.
alayne 12y ago
I'm going to have to disagree. Command line tools can be composed and allow you to do more than the original tool builder provided as well as make it easier to automate tasks. I find it very frustrating to work on systems when everything needs a custom GUI to interact.
- wattson12 12y ago
  I think the point here isn't that command line tools are more powerful in general, its that building a GUI gives that access to more users who aren't as comfortable with the command line. If you don't like the GUI or want to combine into scripts the command line is always there behind the GUI.
  - alayne 12y ago
    That's fair. Sorry, my "GUIs rule" knee jerk reaction flared up. There are a lot of bad GUIs that can give the illusion of helping users, but place upper limits on what you can accomplish. I have been frustrated by various hacked together UIs on top of Linux package management and wrappers around source control tools.
    - wattson12 12y ago
      No worries, I understood where you're coming from. I partly agree with you: I switched to git at the command line from tower because I wanted to script some features (and understand the tool better), but having the GUI there made it easier for me to get used to git in the first place. (though admittedly, tower is one of the good GUIs which make it easy to do a simple task, too many of them do the opposite)
typicalbender 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 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.
emp 12y ago
I agree, though I often use CLI tools due to many GUI tools have let me down. When something goes wrong with git at the command line, there is nothing hidden. That being said, it's a matter of trust - perhaps time to revisit some tools, as the few GUIs I rely on are ones I trust implicitly to do the right thing.
Gracana 12y ago
I really like "commando" from the old macintosh toolbox. It allowed you to create a simple GUI for a command-line tool, complete with checkboxes and text and numeric entries and menus. It showed you the actual command arguments as you selected options, and when you hovered over an option it explained what the option would do. Obviously a lot of tools need a more specialized GUI, but for a lot of simple or moderately complex tools that are used infrequently, it's great. Instead of looking up the man page, you just open the GUI and have the options explained to you while you configure the tool.
- vdm 12y ago
  Commando sounds a little like explainshell.com. It was a part of A/UX, an Apple UNIX which I never knew existed. Screenshot: http://toastytech.com/guis/aux3.html http://toastytech.com/guis/aux3.html Thanks for posting this.
- voltagex_ 12y ago
  I think Platypus will work for this on modern Macs. http://sveinbjorn.org/platypus http://sveinbjorn.org/platypus
GuiA 12y ago
> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. I'd correct that to: The engineering world would be a much better place if more people built beautiful, easy to use command line apps It can be done, although it takes a lot of effort to do well- and a lot of the developers who write CLIs* have very few notions of HCI design. As a result the vast majority of CLIs are inspired from programs that are decades old, and in which no thought was given to the interface, thus perpetuating the cycle. When well executed, a CLI is insanely superior to a GUI on many fronts (with a few exceptions, naturally, such as image/video editing), and more respectful of the users. It is much more friendly to users with vision or motor impairments: any font and any color scheme can be applied, any method of text input can be used, text readers behave in a much more predictable manner, etc. And of course it enables scripting to a level that GUIs just can't compare to. Ideally you'd have a well designed CLI for the users who want it & scripting, and a well designed GUI - but let's face it, doing both is a huge drain of time. If you're going to do one, then a CLI is much, much preferable. On the usability scale, there isn't "CLI apps" on one end and "GUI apps" on the other. Some GUIs are extremely usable, some aren't; some CLIs are extremely usable, some aren't. I am a staunch supporter of the idea that while GUIs became mainstream and CLIs were relegated to a niche position, it should have been the opposite. But we had mediocre CLIs and decent GUIs, so it's only natural that it went that way. Great CLIs would have been preferable on many fronts. Traditionally, the main argument against CLIs is the lack of discoverability that GUIs afford, which is a very valid point. That being said, most CLIs don't make an effort to enhance discoverability, which makes the argument still valid, but a little unfair. Ultimately, I fully subscribe to Jeff Raskin's argument that if you're going to build a tool that users will use on a daily or weekly basis, then it's better to build something with a steep learning curve the first few hours which then results in an efficient and effective tool, rather than something that any newcomer can master within seconds but that will be tedious for extensive use. GUIs that you can master in seconds belong in smartphone apps that you will use a handful of times and then delete a few weeks/months later (this isn't dismissive- if there's a market for it, then it's legitimate). Powerful CLIs that are a bit rough the first handful of hours but become extremely powerful tool belong in your browser, your email client, your text editor, your calendar, and so on: tools that you expect to use for years, if not your lifetime. * : In this comment, by CLI I mean any form of program that runs solely in a command line, but that also includes highly interactive apps built with ncurses etc. There are very, very few command line apps that are solely "type a command, get an output" anymore.
thomaspark 12y ago
Amen to this. Coincidentally, I've been working on a GUI on top of git specifically targeting non-programmers. The goal is to give them an approachable subset of git, help them appreciate its power and potential, and provide them what I call lossless versioning which is missing in so many consumer applications. It's a fun challenge to identify and map git commands to actions that would be familiar to nontechnical audiences.
gdubs 12y ago
It'd be great if more GUI tools were built with the same principles as command-line tools: modularity, interoperability, compactness, textually (in input and output), simplicity.
zecho 12y ago
Until I can chain GUI apps together for my specific needs with some combination of pipes and basic logic, I'm inclined to disagree. GUIs can be really nice for specific apps, but they are often terrible as part of an easily repeated and fast workflow.
- masklinn 12y ago
  > Until I can chain GUI apps together for my specific needs with some combination of pipes and basic logic On OSX, that's what applescript libraries are for.
endgame 12y ago
And the wider world would be a much better place if more people knew the command-line, the Unix philosophy and were able to unlock the true power of their machine.
- coldtea 12y ago
  Would it? Pipes, for one, are not even a properd full featured stream implementation. Most of this power is for obsolete text-based processing. And CLI interfaces are inherently inferior. There's nothing you can do in a CLI you can't do in a GUI (since the GUI can have an additional textual input interface for CLI commands). But GUI adds full color-coding, image capabilities, direct manipulation of objects (with mouse, digitizer, touch, etc), discoverability of commands (they are there on your eyes), and tons of different ways to compose workflows and actions. The only problem is that we don't have a generic GUI stream standard like we have Unix Pipes etc. We only have it for specific apps and domains (e.g Quartz Composer or any video NLE node GUIs). But than again, unix pipes are pretty contrained and specialized themselves. If you're not text-mangling there's not much you can do with the regular userland.
  - a8000 12y ago
    In principle you can add full colors, image capabilities and direct manipulation of objects to a shell, see for example IPython (the Qt-shell) or Mathematica. Ultimately any large enough GUI application will add scripting support, take autocad for example. There are arguably tons of simple applications that are simpler to use if implemented as command line tools, for example video/audio conversion, archival tools
    - coldtea 12y ago
      >In principle you can add full colors, image capabilities and direct manipulation of objects to a shell, see for example IPython (the Qt-shell) or Mathematica. Sure, but I'd call those GUI apps. A GUI app can have textual command input, as it just needs a text entry widget to do so, but a CLI command can not have graphical elements -- since with CLI most people (including me) mean stuff that runs in a terminal, either with command line input or with some curses library.
barbs 12y ago
Bit of a digression, but I use "tig" to interface with git on the command-line. It's basically a curses-based gui for git. It raises an interesting question - is it still a command-line app if it uses curses?
seivan 12y ago
I see the opposite, I see people struggling with Git when using different kinds of application (SourceTree and Tower) Usually I end up helping them by using the command line. Sometimes I install ZSH first to get some nicer colors and autocomplete because they haven't even set that up yet.
BonoboBoner 12y ago
I tend to agree, but all of it isnt available on your production machine, so you'll have to use the cli interface at some point. It is one negative side effect of having not enough females in our industry. It is seen as "manly" to use the most painful tools available (What you use a graphical text editor? Sublime? Use emacs/vim or you are a newb).
rmrfrmrf 12y ago
As a designer, I find command line apps to have exceeding beauty. Design is all about stripping away the unnecessary and producing effective work. Doesn't get much more minimal than that.
neovive 12y ago
Did anyone ever use Norton Commander back in the DOS days (http://en.wikipedia.org/wiki/Norton_Commander http://en.wikipedia.org/wiki/Norton_Commander). It was very well-designed and powerful, text-based, GUI for DOS. The only problem was that once you get used to the GUI, you become dependent on it.

by arrel 12y ago

michaelmior 12y ago

I've never used Tower, but I haven't found diffs and rebasing on the command line to really cause me much trouble. I will agree that there is a segment of users who find such tools useful. I think part of the problem is that the segment of people who want GUI tools and the segment of people who build the underlying tools rarely overlap.

Osmium 12y ago

> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. I can't tell you how much I agree with this. Far too little engineering effort is spent on nice GUIs, especially for 'niche' applications (I'm talking the sciences here in particular), because the GUI doesn't add any functionality. It's true, but it sure as hell adds productivity. In regards to homebrew specifically though, I think the 'brew' command line app is actually one of the better ones and is actually pretty easy to use.

aroch 12y ago
>I'm talking the sciences here in particular Heh, tell me about it. There are better programs out there but we still use some written 20 years ago because they have a UI.
- jwarren 12y ago
  This is startlingly true. The more I dive into development and open-source solutions, the more worrying this becomes. Edit: to maybe relieve the concerns of downvoters: I find it worrying because there are lots of generally productive and intelligent people who will avoid command line tools as much as possible. These are some very good programmers. This means that tools as simple as Grunt are deemed to be "too much fuss." I'm a big user and supporter of OSS, and I try and promote it as much as possible within my colleagues and peer group. I've had some success, but that's really another story for another time.
  - aroch 12y ago
    I was "volunteered" to maintain some old scripts that we use in the lab, some were written in Algol. The older the lab/institution the more worryingly old software is required by the researchers (Don't even ask about centrifuges that should have been retired almost a trillion revs ago).

pjmlp 12y ago

I feel the same way. Amiga and environments like Smalltalk and Oberon spoiled me for GUIs. I do master the CLI across multiple OSs, but only use them when I really need to.

ihuman 12y ago

Is homebrew that confusing though? I thought it was much simpler compared to other CLIs. Primarily, all you do is search, install, and uninstall.

TillE 12y ago
And update/upgrade, and the occasional cleanup. It really is extremely simple, and I don't know why anyone would be using Homebrew if they're not already comfortable with the command line.
- GuiA 12y ago
  The modern programming movements, especially web development, have created many developers who can do (for example) some HTML, some CSS, a little bit of {Rails | Django | PHP}, a little bit of {Angular | JQuery | Ember.js }, etc. but are very uncomfortable with concepts/tools that a lot of hackers take for granted (using a command line being one example). Not saying it's a good thing or a bad thing, just how it is (especially with things like programming bootcamps and associate degrees focused on quick web development). Some of us have been swimming in Linux and obscure hacker culture for decades, and we forget that maybe one doesn't need the huge entire body of knowledge we have to be productive employees in a certain capacity?
  - malvosenior 12y ago
    It's a bad thing.
  - hippee-lee 12y ago
    > Not saying it's a good thing or a bad thing The tools we use are neither good nor bad. How well we use them, what we use them for and how we teach others to use them are what makes the good or bad. I love the way you make this conversation good with a pragmatic point of view and an opinionated but reasonable voice. Thank you.
jwarren 12y ago
IMO it has a really nice interface for a CLI. Lots of sensible colour coding and some of the clearest instructions/error messages I've come across.

alayne 12y ago

I'm going to have to disagree. Command line tools can be composed and allow you to do more than the original tool builder provided as well as make it easier to automate tasks. I find it very frustrating to work on systems when everything needs a custom GUI to interact.

wattson12 12y ago
I think the point here isn't that command line tools are more powerful in general, its that building a GUI gives that access to more users who aren't as comfortable with the command line. If you don't like the GUI or want to combine into scripts the command line is always there behind the GUI.
- alayne 12y ago
  That's fair. Sorry, my "GUIs rule" knee jerk reaction flared up. There are a lot of bad GUIs that can give the illusion of helping users, but place upper limits on what you can accomplish. I have been frustrated by various hacked together UIs on top of Linux package management and wrappers around source control tools.
  - wattson12 12y ago
    No worries, I understood where you're coming from. I partly agree with you: I switched to git at the command line from tower because I wanted to script some features (and understand the tool better), but having the GUI there made it easier for me to get used to git in the first place. (though admittedly, tower is one of the good GUIs which make it easy to do a simple task, too many of them do the opposite)

typicalbender 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 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.

emp 12y ago

I agree, though I often use CLI tools due to many GUI tools have let me down. When something goes wrong with git at the command line, there is nothing hidden. That being said, it's a matter of trust - perhaps time to revisit some tools, as the few GUIs I rely on are ones I trust implicitly to do the right thing.

Gracana 12y ago

I really like "commando" from the old macintosh toolbox. It allowed you to create a simple GUI for a command-line tool, complete with checkboxes and text and numeric entries and menus. It showed you the actual command arguments as you selected options, and when you hovered over an option it explained what the option would do. Obviously a lot of tools need a more specialized GUI, but for a lot of simple or moderately complex tools that are used infrequently, it's great. Instead of looking up the man page, you just open the GUI and have the options explained to you while you configure the tool.

vdm 12y ago
Commando sounds a little like explainshell.com. It was a part of A/UX, an Apple UNIX which I never knew existed. Screenshot: http://toastytech.com/guis/aux3.html http://toastytech.com/guis/aux3.html Thanks for posting this.
voltagex_ 12y ago
I think Platypus will work for this on modern Macs. http://sveinbjorn.org/platypus http://sveinbjorn.org/platypus

GuiA 12y ago

> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. I'd correct that to: The engineering world would be a much better place if more people built beautiful, easy to use command line apps It can be done, although it takes a lot of effort to do well- and a lot of the developers who write CLIs* have very few notions of HCI design. As a result the vast majority of CLIs are inspired from programs that are decades old, and in which no thought was given to the interface, thus perpetuating the cycle. When well executed, a CLI is insanely superior to a GUI on many fronts (with a few exceptions, naturally, such as image/video editing), and more respectful of the users. It is much more friendly to users with vision or motor impairments: any font and any color scheme can be applied, any method of text input can be used, text readers behave in a much more predictable manner, etc. And of course it enables scripting to a level that GUIs just can't compare to. Ideally you'd have a well designed CLI for the users who want it & scripting, and a well designed GUI - but let's face it, doing both is a huge drain of time. If you're going to do one, then a CLI is much, much preferable. On the usability scale, there isn't "CLI apps" on one end and "GUI apps" on the other. Some GUIs are extremely usable, some aren't; some CLIs are extremely usable, some aren't. I am a staunch supporter of the idea that while GUIs became mainstream and CLIs were relegated to a niche position, it should have been the opposite. But we had mediocre CLIs and decent GUIs, so it's only natural that it went that way. Great CLIs would have been preferable on many fronts. Traditionally, the main argument against CLIs is the lack of discoverability that GUIs afford, which is a very valid point. That being said, most CLIs don't make an effort to enhance discoverability, which makes the argument still valid, but a little unfair. Ultimately, I fully subscribe to Jeff Raskin's argument that if you're going to build a tool that users will use on a daily or weekly basis, then it's better to build something with a steep learning curve the first few hours which then results in an efficient and effective tool, rather than something that any newcomer can master within seconds but that will be tedious for extensive use. GUIs that you can master in seconds belong in smartphone apps that you will use a handful of times and then delete a few weeks/months later (this isn't dismissive- if there's a market for it, then it's legitimate). Powerful CLIs that are a bit rough the first handful of hours but become extremely powerful tool belong in your browser, your email client, your text editor, your calendar, and so on: tools that you expect to use for years, if not your lifetime. * : In this comment, by CLI I mean any form of program that runs solely in a command line, but that also includes highly interactive apps built with ncurses etc. There are very, very few command line apps that are solely "type a command, get an output" anymore.

thomaspark 12y ago

Amen to this. Coincidentally, I've been working on a GUI on top of git specifically targeting non-programmers. The goal is to give them an approachable subset of git, help them appreciate its power and potential, and provide them what I call lossless versioning which is missing in so many consumer applications. It's a fun challenge to identify and map git commands to actions that would be familiar to nontechnical audiences.

gdubs 12y ago

It'd be great if more GUI tools were built with the same principles as command-line tools: modularity, interoperability, compactness, textually (in input and output), simplicity.

zecho 12y ago

Until I can chain GUI apps together for my specific needs with some combination of pipes and basic logic, I'm inclined to disagree. GUIs can be really nice for specific apps, but they are often terrible as part of an easily repeated and fast workflow.

masklinn 12y ago
> Until I can chain GUI apps together for my specific needs with some combination of pipes and basic logic On OSX, that's what applescript libraries are for.

endgame 12y ago

And the wider world would be a much better place if more people knew the command-line, the Unix philosophy and were able to unlock the true power of their machine.

coldtea 12y ago
Would it? Pipes, for one, are not even a properd full featured stream implementation. Most of this power is for obsolete text-based processing. And CLI interfaces are inherently inferior. There's nothing you can do in a CLI you can't do in a GUI (since the GUI can have an additional textual input interface for CLI commands). But GUI adds full color-coding, image capabilities, direct manipulation of objects (with mouse, digitizer, touch, etc), discoverability of commands (they are there on your eyes), and tons of different ways to compose workflows and actions. The only problem is that we don't have a generic GUI stream standard like we have Unix Pipes etc. We only have it for specific apps and domains (e.g Quartz Composer or any video NLE node GUIs). But than again, unix pipes are pretty contrained and specialized themselves. If you're not text-mangling there's not much you can do with the regular userland.
- a8000 12y ago
  In principle you can add full colors, image capabilities and direct manipulation of objects to a shell, see for example IPython (the Qt-shell) or Mathematica. Ultimately any large enough GUI application will add scripting support, take autocad for example. There are arguably tons of simple applications that are simpler to use if implemented as command line tools, for example video/audio conversion, archival tools
  - coldtea 12y ago
    >In principle you can add full colors, image capabilities and direct manipulation of objects to a shell, see for example IPython (the Qt-shell) or Mathematica. Sure, but I'd call those GUI apps. A GUI app can have textual command input, as it just needs a text entry widget to do so, but a CLI command can not have graphical elements -- since with CLI most people (including me) mean stuff that runs in a terminal, either with command line input or with some curses library.

barbs 12y ago

Bit of a digression, but I use "tig" to interface with git on the command-line. It's basically a curses-based gui for git. It raises an interesting question - is it still a command-line app if it uses curses?

seivan 12y ago

I see the opposite, I see people struggling with Git when using different kinds of application (SourceTree and Tower) Usually I end up helping them by using the command line. Sometimes I install ZSH first to get some nicer colors and autocomplete because they haven't even set that up yet.

BonoboBoner 12y ago

I tend to agree, but all of it isnt available on your production machine, so you'll have to use the cli interface at some point. It is one negative side effect of having not enough females in our industry. It is seen as "manly" to use the most painful tools available (What you use a graphical text editor? Sublime? Use emacs/vim or you are a newb).

rmrfrmrf 12y ago

As a designer, I find command line apps to have exceeding beauty. Design is all about stripping away the unnecessary and producing effective work. Doesn't get much more minimal than that.

neovive 12y ago

Did anyone ever use Norton Commander back in the DOS days (http://en.wikipedia.org/wiki/Norton_Commander http://en.wikipedia.org/wiki/Norton_Commander). It was very well-designed and powerful, text-based, GUI for DOS. The only problem was that once you get used to the GUI, you become dependent on it.