Mice are not a 100% replacement for keyboards. If you're doing lots of typing, there is something to be said for keeping your hands on the keyboard. Vim and emacs facilitate this much better than GUI-based editors.
>On the other hand, mice-based GUIs ARE a 100% replacement for CLIs.
Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs.
(Points deducted for anything that involves instructing the machine to "move mouse to position (x,y)", since screen sizes may vary and where an individual GUI chooses to pop open a dialog/modal may also vary)
I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI.
That's true enough, although honestly I'm at a point in my computing where the G part of the GUI is pretty limited: my windows are all full-screen; the only clicking I regularly do is on links and tabs, and sometimes text (honestly, I'm trying to use the keyboard more for that though); almost all of my command execution is keyboard-driven (there's a reason man developed language rather than pointing and grunting).
> I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI.
That's not strictly fair because running ncurses applications inside split tmux panes would give you a GUI-like UI inside a command line environment. Also some of the more esoteric WM's would provide that kind of functionality as well.
The main reason it's more common to run CLI inside a GUI is really just a matter of convenience.
There's no reason you can't have a CLI interface with graphics support. Granted the vt100-style terminals can't easily do it, but it was possible with the old REPL machines of the 80s (eg most micro computers which booted into a BASIC interpreter).
There are some also some terminal emulators in Linux that support inlined graphics, however I'm not sure how easy it would be to run them as a WM.
Firstly, Bash et al is a REPL in it's own right. What you're discussing there is that UNIX shells make a rubbish programming environment, which is a completely different argument to anything that was being discussed here. For example, DOS can inline graphics as well (proper DOS, not Windows' cmd.exe). So to follow the linked tangent you've made: DOSbox is also a better REPL than UNIX shells. Obviously neither of us would agree with that - even with our criticism of Bash et al. So equally your implied correlation is false.
Secondly, your point about "interaction with the complete OS stack", suggesting that CLI interfaces don't have access to the complete OS stack, is completely wrong. If that were the case then Linux and UNIX servers wouldn't typically run headless. A GUI is a shell. The CLI is a shell. Some platforms place more love to graphical shells than command line shells (eg Windows). Other platforms empower command line shells (eg UNIX). To argue that one is better than another is about as futile as saying the colour purple is better than the colour orange. In short, it's personal preference; not irrefutable fact.
UNIX shells aren't a REPL because 99% of their features are implemented in external commands. The shell is reduced to orchestrate logic between those commands.
None of the common ones, ash, sh, bash.... provide a rich programming environment that doesn't rely on external commands.
Interaction with the whole OS goes back to Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon REPL experiences. Nothing to do with running headless, which means you didn't got the message.
In those environments I can via the REPL directly interact with running applications from the REPL. For example, search for a specific text in all open windows and act upon it if found.
The whole OS API is exposed in the REPL via library calls.
No UNIX shell provides this expressiveness without relying on external commands and applications implementing specific APIs like dbus.
>Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs.
Yes, you can, and we have been doing it for decades, e.g. Automator on OS X.
Especially stuff like this is quite easily achievable: "query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs".
Not only that, but pipeline steps can trivially include "run a specific cli program with this as an input and pass the output to another program" (where the previous/after program can be GUI or CLI or a remote service, etc).
Nothing precludes a program with a GUI from taking formal parameters (in whatever format) and being scriptable and pipelined to other such programs.
Whether your question is if this is true for a particular program P, it might, or it might not. That's no different from command line programs which might or might not be pipeline-able between them without intermediaries doing custom scraping, parsing and massaging.
Other scriptable solutions for GUI programs but without GUI-based visual mixing and matching of pipelines include Applescript (and it's Javascript incarnation), Microsoft PowerShell, etc. This are textual based, but not CLI -- you can run them from an IDE for all the extra power that gives.
Also macro recording/playing (available in lots of GUI apps) means you don't have to write anything like "click window at pixel x,y".
And of course in the trivial case, a mice GUI can run any terminal emulator too -- making it a superset of CLI, since the GUI terminal can also include buttons, menus, show images, etc -- which a command line interface cannot -- so it gets the best of both worlds.
Yeah, so can AutoIT or python with pywinauto... you could do it. It just wouldn't be pleasant. Might do it if you had to extract data from some proprietary GUI tool you couldn't tear open.
While more complicated, CLIs tend to be more expressive, easier to program as a platform and simpler to communicate between than GUIs.
Expressive, because they are built on top of (and as a part of) languages. You can do this in a GUI, but it seems to be rare; instead the program typically defines how you manage inputs and outputs.
They are easy to program for. GUIs typically require an additional framework (and are still difficult to build).
CLI typically communicates over plain text. Getting two GUI programs to talk to each other is typically very difficult. You can string a bundle of CLI commands together and build new functionality, but this is much more difficult with a GUI. This is partly a philosophical difference; the CLI platform encourages plaintext interop, but a GUI platform typically encourages isolated programs (possibly with API).
That said, nothing is perfect. There are plenty of instances were a GUI is better. People can understand visual data better and notably it's far easier to understand in an intuitive way. But it's certainly not a 100% replacement.
If you're willing to say a mouse GUI is 100% replacement for CLI, then I don't see why you can't argue that a clicking on a virtual keyboard makes physical keyboards obsolete.
Because CLI and keyboard access are two different things.
The fact that one can do all CLI work on a GUI doesn't mean that typing on a virtual keyboard is as convenient as typing on a physical one for typing tasks.
Are people under the impression that mice GUIs mean that one doesn't use the keyboard? Mice GUIs have both shortcuts AND text entry boxes a-plenty. They even have terminals.
It's the CLI that doesn't have access to all these stuff.
