4 ms·

>After thinking about it for a while, my conclusion is that there are two main reasons that most programmers prefer CLIs to GUIs He's missing the most obvious

>After thinking about it for a while, my conclusion is that there are two main reasons that most programmers prefer CLIs to GUIs He's missing the most obvious reason. Programmers love... wait for it... programmable interfaces. A GUI doesn't generally allow me to programmatically define its behavior or pipe the output to a different GUI of my choice. Incidentally, Windows' command prompt sucked for a very long time due to its limited scriptability. (Today, the Windows PowerShell mostly solves the issue if you know what you are doing.)

cool-RR 15y ago
A good GUI made for programmers, like Wing IDE, will let you write your own scripts for it and extend it to do anything you want. Also, I think that most of the work that people do, even programmers, is spent doing simple tasks. The median shell command is more like a `cd` rather than a triple-piped command. So use GUIs for the common tasks, and when you need something more complex, use the CLI. The general point is that I'm pitting the very best GUIs against the very best CLIs.
- ordinary 15y ago
  In the blog entry, you say you compared the "very best GUIs" to the "very best CLIs". At the risk of triggering a holy war, which GUIs and CLIs do you feel fit those categories? It's hard to say anything sensible when we don't know the specifics.
  - cool-RR 15y ago
    I mentioned some of my favorite GUIs in the post. These are only GUIs that are relevant to my niche, there's a whole world of GUIs out there that I haven't heard about.
- merlincorey 15y ago
  This is not the same as the main point of the parent comment, which is the bottom-up philosophy of small simple procedures that can be combined to create even more useful procedures with variety and ease... This is the Unix philosophy, and this is what we (the terminal-enjoyers) enjoy most about it. When I can "pipe" the output from one component within a GUI program to another (of which there have been a few interesting research ventures), or even from one GUI program to another, and also automate this whole process with things like loops and conditionals on a whim (not just from scripts stored in files, but invented on the spot as needed) without resorting to writing a plugin to a program-specific API, then we will be on the same page. GUIs don't have as useful of a REPL, but this could be fixed. GUIs don't have a programmable shell[1] that provides the conditionals and loops needed for automation, but this could be fixed. Just post it to Hacker News when it is fixed! [1] edit - Well, myself and others run stumpWM; which, being Common Lisp based, does provide a bit of a programmable shell and REPL, but this is not the norm for KDE, Gnome, etc.
galactus 15y ago
I came here to say the same. The ability to drive and connect commands programatically is what makes the CLI so powerful. Sure, some GUIs let you extend them via some embedded scripting language, but nothing beats single-use bash scripts in many, many cases.
ch0wn 15y ago
Agreed. We could the git example a step further and define an alias for it and make 'git che[tab] master' 'git c master'. With an alias as shell level we could even make it 'gc master'. But the real benefits lie in automation of tasks like git-flow allows you to. Sure, it's theoretically possible for GUIs to provide interfaces that allow a similar level of customization and automation, but I can't think of a good example.
- cool-RR 15y ago
  I could make a one-keystroke shortcut on the GUI too using AutoHotKey, but I wouldn't because of the usual problems and restrictions (Having to do it, having to maintain these for all your computers, having clashes with other programs...)

cool-RR 15y ago

A good GUI made for programmers, like Wing IDE, will let you write your own scripts for it and extend it to do anything you want. Also, I think that most of the work that people do, even programmers, is spent doing simple tasks. The median shell command is more like a `cd` rather than a triple-piped command. So use GUIs for the common tasks, and when you need something more complex, use the CLI. The general point is that I'm pitting the very best GUIs against the very best CLIs.

ordinary 15y ago
In the blog entry, you say you compared the "very best GUIs" to the "very best CLIs". At the risk of triggering a holy war, which GUIs and CLIs do you feel fit those categories? It's hard to say anything sensible when we don't know the specifics.
- cool-RR 15y ago
  I mentioned some of my favorite GUIs in the post. These are only GUIs that are relevant to my niche, there's a whole world of GUIs out there that I haven't heard about.
merlincorey 15y ago
This is not the same as the main point of the parent comment, which is the bottom-up philosophy of small simple procedures that can be combined to create even more useful procedures with variety and ease... This is the Unix philosophy, and this is what we (the terminal-enjoyers) enjoy most about it. When I can "pipe" the output from one component within a GUI program to another (of which there have been a few interesting research ventures), or even from one GUI program to another, and also automate this whole process with things like loops and conditionals on a whim (not just from scripts stored in files, but invented on the spot as needed) without resorting to writing a plugin to a program-specific API, then we will be on the same page. GUIs don't have as useful of a REPL, but this could be fixed. GUIs don't have a programmable shell[1] that provides the conditionals and loops needed for automation, but this could be fixed. Just post it to Hacker News when it is fixed! [1] edit - Well, myself and others run stumpWM; which, being Common Lisp based, does provide a bit of a programmable shell and REPL, but this is not the norm for KDE, Gnome, etc.

galactus 15y ago

I came here to say the same. The ability to drive and connect commands programatically is what makes the CLI so powerful. Sure, some GUIs let you extend them via some embedded scripting language, but nothing beats single-use bash scripts in many, many cases.

ch0wn 15y ago

Agreed. We could the git example a step further and define an alias for it and make 'git che[tab] master' 'git c master'. With an alias as shell level we could even make it 'gc master'. But the real benefits lie in automation of tasks like git-flow allows you to. Sure, it's theoretically possible for GUIs to provide interfaces that allow a similar level of customization and automation, but I can't think of a good example.

cool-RR 15y ago
I could make a one-keystroke shortcut on the GUI too using AutoHotKey, but I wouldn't because of the usual problems and restrictions (Having to do it, having to maintain these for all your computers, having clashes with other programs...)