6 ms·

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 ema

by cicero 11y ago

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.

coldtea 11y ago
>Mice are not a 100% replacement for keyboards. And they're not used as such. They are used as complimentary to keyboards. On the other hand, mice-based GUIs ARE a 100% replacement for CLIs.
- ubertaco 11y ago
  >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)
  - adrianN 11y ago
    AppleScript can do pretty complex GUI automation tasks.
    - ultramancool 11y ago
      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.
    - Zardoz84 11y ago
      Windows 3.1 had a macro recorder that allow to automate task over a GUI.
  - zeveb 11y ago
    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).
    - laumars 11y ago
      > 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.
      - coldtea 11y ago
        You also get access to the whole world of GUI applications. Watching video and editing pictures is not much fun with only ncurses... (ascii video hardly took the world by storm).
        laumars 11y ago
        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.
        pjmlp 11y ago
        Hence why we GUI guys rather use a REPL than a plain UNIX CLI. Graphics, the expressiveness of a sane programming language and interaction with the complete OS stack.
  - coldtea 11y ago
    >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.
- Joof 11y ago
  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.
- Retra 11y ago
  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.
  - coldtea 11y ago
    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.
deleted 11y ago
[deleted]

by cicero 11y ago

coldtea 11y ago

>Mice are not a 100% replacement for keyboards. And they're not used as such. They are used as complimentary to keyboards. On the other hand, mice-based GUIs ARE a 100% replacement for CLIs.

ubertaco 11y ago
>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)
- adrianN 11y ago
  AppleScript can do pretty complex GUI automation tasks.
  - ultramancool 11y ago
    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.
  - Zardoz84 11y ago
    Windows 3.1 had a macro recorder that allow to automate task over a GUI.
- zeveb 11y ago
  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).
  - laumars 11y ago
    > 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.
    - coldtea 11y ago
      You also get access to the whole world of GUI applications. Watching video and editing pictures is not much fun with only ncurses... (ascii video hardly took the world by storm).
      - laumars 11y ago
        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.
        pjmlp 11y ago
        Hence why we GUI guys rather use a REPL than a plain UNIX CLI. Graphics, the expressiveness of a sane programming language and interaction with the complete OS stack.
- coldtea 11y ago
  >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.
Joof 11y ago
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.
Retra 11y ago
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.
- coldtea 11y ago
  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.

deleted 11y ago

[deleted]