7 ms·

CLI and GUI have different grammars and capabilities. If you think that CLI means "prehistory" and GUI means "future", then ask yourself why CLI has "survived"

CLI and GUI have different grammars and capabilities. If you think that CLI means "prehistory" and GUI means "future", then ask yourself why CLI has "survived" GUI for at least 30 years.

pjmlp 10y ago
Has it? Sure it is down there on the OS tooling, but how many people outside UNIX devs, do actually bother using it? Personally it doesn't offer me any benefit over an higher level programming language REPL.
- dualogy 10y ago
  Silly flamefest this. Even back when I worked mostly for Windows/MS shops or clients, writing CLI tooling for business (not developer) needs were often the order of the day. Batch import/export tools and what not. Also prototypes of daemon-like Windows Services for client testing. All kinds of tools that weren't directly developer tools. Sure enough, we were interfacing with IT folks at the client end but still, no programmers per se! There's a reason GUI starts with a G. Other than "graphical" user interfaces, "other" user interfaces will also always have their place.. In some ways looking at how much non-developer computer usage in the past decades has been in front of excel/access sheets and tables, these aren't so "graphical" either. They essentially end up evolving into (haphazard) custom CLI-like keyboard-driven power tools, half-programmable, half requiring intimate familiarity with its "commands" (formulas) or even "training" to use them fluidly. But if you'd rather code out your CLI needs in a PL REPL (aka CLI), more power to you ;D
- Gravityloss 10y ago
  Interesting, I assume you do development? How do you handle scripting, moving files, grepping logs etc?
  - pjmlp 10y ago
    GUI tooling? Languages like Python?
    - umanwizard 10y ago
      How would you do this with GUI tooling: Find all files containing a particular string in a directory tree. For each of those files, if its filename appears in a file called Whitelist, write it to a file called Output. Otherwise, do nothing. Here is one possible command line version (I haven't tested it as I'm on mobile): TMPF=`mktemp /tmp/XXXXXXXX` && ag MyString | awk -F: '{print $1}' | sort | uniq > $TMPF && comm -12 Whitelist $TMPF > Output && rm $TMPF
      - hawski 10y ago
        You probably could use process substitution to get rid of the temp file: comm -12 Whitelist <(ag MyString | awk -F: '{print $1}' | sort | uniq) > Output Then you could use unique flag of sort: comm -12 Whitelist <(ag MyString | awk -F: '{print $1}' | sort -u) > Output Also ag can list only matching files (getting rid of awk and unique): comm -12 Whitelist <(ag -l MyString | sort) > Output
        umanwizard 10y ago
        Thanks for the tips!
      - belltaco 10y ago
        Would be trivial to write a GUI program to do the same.
        umanwizard 10y ago
        I think it would take at least a half hour, unless you have directory traversal, file I/O, and regex APIs memorized which most people don't. That's "trivial" in the grand scheme of things but it's really not practical to do day-in and day-out every time some random scripting necessity arises. And you presumably have to clutter up your filesystem with random project files, etc, which is annoying. Are you going to have 1000 of these, one for every time you need to do some sort of minor task like this? That command, on the other hand, took me 2 or 3 minutes to write, and I had to look up the syntax for `mktemp`. If I had remembered the mktemp syntax it would have taken a few seconds.
- AnonymousPlanet 10y ago
  At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI, one just hadn't yet figured out how. The GUI, however, never delivered those last 10-20% that you need in automation or in a context that requires reproducibility. Windows NT was designed towards those promises, but eventually Microsoft realised their mistake and created - ten years ago - Powershell. The entire dev world has been catching on to the fact that you get reproducible procedures when you use a CLI. Data scientists are another group who know how much power they get from a CLI. Yet the myth of the obsolete CLI and the omnipotent GUI still is strong. Especially with those people who never really worked with a decent CLI.
  - coldtea 10y ago
    >At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.
    - bluejekyll 10y ago
      Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. The CLI offers an infinitely combinable and customizable development experience, where huge ammounts of innovation have been occuring. You can see this in modern web development toolchains and new build tools for new languages, which simply would not happen if you restrict your Dev experience to just the GUI. I keep going back to just creating Makefiles for simple automation tasks. Even the GUIs are starting to learn from this, which is why I think VSCode and Atom are becoming popular; they make it very simple to integrate new CLI tools into the GUIs workflow.
      - coldtea 10y ago
        >Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. No, I'm speaking from the perspective of someone that has worked in the old days with Sun OS (pre-Solaris) workstations and HP-UX machines, has used (for years) actual VT102 terminals, started using Linux distros around '97 and has been using the CLI in various forms since the mid-eighties or so. There's nothing limited about the GUI (in theory, and, for most things that matter, in practice too). For example a visual flow language (think Automator in OS X or Quartz Composer, etc) can achieve all the "configurable pipeline" stuff people like in the CLI in a more controlled and formal way. I also dislike the "dynamic typing" (everything is text/bytes) in the CLI, and would prefer something like PowerShell to have been the norm (with the accompanying toolset). Also note that there's nothing about the GUI that prevents someone from typing some commands too -- and in fact that's part of how lots of GUIs work. Also, I wouldn't point to "modern web development toolchains" as something to advertise CLIs -- what would that be, Gulp, Grunt, Webpack and the like? All crufty solutions to inadequacies in steering the underlying language properly. Even in theory, CLIs are not inherently more powerful, it's the other way around (they lack a dimension that GUIs offer (graphics) -- GUIs on the other hand don't lack any dimension -- they can incorporate text commands and text fields and pipelines just fine.
- lomnakkus 10y ago
  Yes, it has. I mean there may not be as many users, but they are massively more powerful (in the realm of data processing only, alas) than people who don't know the CLI. It may be obvious to us, but I should perhaps also point out that CLI ~= REPL for the language that you're using (Bash or whatever). Sure, these days CLI may mean "a Jupyter notebook", but the same principle applies. It may not always look the same, but the point is that a CLI/REPL should be a combinatorial force multiplier. Otherwise, it's not really worthwhile.

CLI and GUI have different grammars and capabilities. If you think that CLI means "prehistory" and GUI means "future", then ask yourself why CLI has "survived" GUI for at least 30 years.

pjmlp 10y ago

Has it? Sure it is down there on the OS tooling, but how many people outside UNIX devs, do actually bother using it? Personally it doesn't offer me any benefit over an higher level programming language REPL.

dualogy 10y ago
Silly flamefest this. Even back when I worked mostly for Windows/MS shops or clients, writing CLI tooling for business (not developer) needs were often the order of the day. Batch import/export tools and what not. Also prototypes of daemon-like Windows Services for client testing. All kinds of tools that weren't directly developer tools. Sure enough, we were interfacing with IT folks at the client end but still, no programmers per se! There's a reason GUI starts with a G. Other than "graphical" user interfaces, "other" user interfaces will also always have their place.. In some ways looking at how much non-developer computer usage in the past decades has been in front of excel/access sheets and tables, these aren't so "graphical" either. They essentially end up evolving into (haphazard) custom CLI-like keyboard-driven power tools, half-programmable, half requiring intimate familiarity with its "commands" (formulas) or even "training" to use them fluidly. But if you'd rather code out your CLI needs in a PL REPL (aka CLI), more power to you ;D
Gravityloss 10y ago
Interesting, I assume you do development? How do you handle scripting, moving files, grepping logs etc?
- pjmlp 10y ago
  GUI tooling? Languages like Python?
  - umanwizard 10y ago
    How would you do this with GUI tooling: Find all files containing a particular string in a directory tree. For each of those files, if its filename appears in a file called Whitelist, write it to a file called Output. Otherwise, do nothing. Here is one possible command line version (I haven't tested it as I'm on mobile): TMPF=`mktemp /tmp/XXXXXXXX` && ag MyString | awk -F: '{print $1}' | sort | uniq > $TMPF && comm -12 Whitelist $TMPF > Output && rm $TMPF
    - hawski 10y ago
      You probably could use process substitution to get rid of the temp file: comm -12 Whitelist <(ag MyString | awk -F: '{print $1}' | sort | uniq) > Output Then you could use unique flag of sort: comm -12 Whitelist <(ag MyString | awk -F: '{print $1}' | sort -u) > Output Also ag can list only matching files (getting rid of awk and unique): comm -12 Whitelist <(ag -l MyString | sort) > Output
      - umanwizard 10y ago
        Thanks for the tips!
    - belltaco 10y ago
      Would be trivial to write a GUI program to do the same.
      - umanwizard 10y ago
        I think it would take at least a half hour, unless you have directory traversal, file I/O, and regex APIs memorized which most people don't. That's "trivial" in the grand scheme of things but it's really not practical to do day-in and day-out every time some random scripting necessity arises. And you presumably have to clutter up your filesystem with random project files, etc, which is annoying. Are you going to have 1000 of these, one for every time you need to do some sort of minor task like this? That command, on the other hand, took me 2 or 3 minutes to write, and I had to look up the syntax for `mktemp`. If I had remembered the mktemp syntax it would have taken a few seconds.
AnonymousPlanet 10y ago
At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI, one just hadn't yet figured out how. The GUI, however, never delivered those last 10-20% that you need in automation or in a context that requires reproducibility. Windows NT was designed towards those promises, but eventually Microsoft realised their mistake and created - ten years ago - Powershell. The entire dev world has been catching on to the fact that you get reproducible procedures when you use a CLI. Data scientists are another group who know how much power they get from a CLI. Yet the myth of the obsolete CLI and the omnipotent GUI still is strong. Especially with those people who never really worked with a decent CLI.
- coldtea 10y ago
  >At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.
  - bluejekyll 10y ago
    Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. The CLI offers an infinitely combinable and customizable development experience, where huge ammounts of innovation have been occuring. You can see this in modern web development toolchains and new build tools for new languages, which simply would not happen if you restrict your Dev experience to just the GUI. I keep going back to just creating Makefiles for simple automation tasks. Even the GUIs are starting to learn from this, which is why I think VSCode and Atom are becoming popular; they make it very simple to integrate new CLI tools into the GUIs workflow.
    - coldtea 10y ago
      >Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. No, I'm speaking from the perspective of someone that has worked in the old days with Sun OS (pre-Solaris) workstations and HP-UX machines, has used (for years) actual VT102 terminals, started using Linux distros around '97 and has been using the CLI in various forms since the mid-eighties or so. There's nothing limited about the GUI (in theory, and, for most things that matter, in practice too). For example a visual flow language (think Automator in OS X or Quartz Composer, etc) can achieve all the "configurable pipeline" stuff people like in the CLI in a more controlled and formal way. I also dislike the "dynamic typing" (everything is text/bytes) in the CLI, and would prefer something like PowerShell to have been the norm (with the accompanying toolset). Also note that there's nothing about the GUI that prevents someone from typing some commands too -- and in fact that's part of how lots of GUIs work. Also, I wouldn't point to "modern web development toolchains" as something to advertise CLIs -- what would that be, Gulp, Grunt, Webpack and the like? All crufty solutions to inadequacies in steering the underlying language properly. Even in theory, CLIs are not inherently more powerful, it's the other way around (they lack a dimension that GUIs offer (graphics) -- GUIs on the other hand don't lack any dimension -- they can incorporate text commands and text fields and pipelines just fine.
lomnakkus 10y ago
Yes, it has. I mean there may not be as many users, but they are massively more powerful (in the realm of data processing only, alas) than people who don't know the CLI. It may be obvious to us, but I should perhaps also point out that CLI ~= REPL for the language that you're using (Bash or whatever). Sure, these days CLI may mean "a Jupyter notebook", but the same principle applies. It may not always look the same, but the point is that a CLI/REPL should be a combinatorial force multiplier. Otherwise, it's not really worthwhile.