12 ms·

> Why is it broken by design? I think your example self-explains why it's broken by design. It's a good example. > a command line interface must be human read

> Why is it broken by design? I think your example self-explains why it's broken by design. It's a good example. > a command line interface must be human readable and machine readable at the same time. There is no canonical way to solve this problem. And you know, there could be one. Apple has Human Interface Guidelines to reify the meaning of the visual abstractions in its desktop UI. The problem is that the command line didn't come from people who think like Apple designers; it came from people who think "How can I express what I want using the least code possible, because laziness, impatience, and hubris are virtues?" And they weren't wrong for the time (especially because every byte matters), but the design decisions they made got baked into tooling that can't now be moved. I think at this point we'd have to punt the POSIX toolchain to get something better; it's hard for me to imagine how we'd build discoverable, conceptually-consistent UX atop what we currently have.

ceving 3y ago
I think graphical user interfaces are no high standard. They do not compose. How would you express a loop or a recursion in a graphical user interface?
- shadowgovt 3y ago
  They are a challenge for composition, often. Great for discoverability though, and that doesn't require graphics, just context. There should be a button I can push in my shell that lets me ask "what does the token at cursor mean," and a button that lets me type a plain language search string that wires down to a contextual search (i.e. I'm in the middle of typing out "grep" I should be able to ask "how do I search folders?"). We didn't have the tools to build this when grep was invented; we have them now.
- samatman 3y ago
  I'm genuinely unsure how to translate your question into, hmm. Anything actually. The snarky answer is "By writing it in source code, in a GUI text editor", a thing I do frequently. But the problem is that I have no idea what you're getting at in the first place, so that's just an attempt to recover some meaning from what you wrote.
  - shadowgovt 3y ago
    Shells allow one to pipe around the data flowing from called process to called process in a very smooth and transparent fashion. By and large, GUIs do not. There is no such thing as a universal shell for GUIs, and attempts to layer automation atop the GUI abstraction are generally spotty and unreliable (certainly when compared to CLI and shells). This is both for technical reasons (i.e. it's much easier to clearly delineate the two ends of a pipe than to clearly delineate "I want to click on the red square inside the 'diagram' window inside the drawing app") and for ecosystem reasons (since GUIs aren't thought of as automatable, GUI designers are free to move pieces around version-to-version of software, making it extremely challenging to describe a GUI structurally). I've seen some neat attempts at GUI automation (Sikuli is my favorite) but it's never been a core feature like it is in the CLIs-glued-together-by-shells world.
    - samatman 3y ago
      CLIs are in the modern world a subset of GUI programs which run inside a text-oriented window, and plenty of more sophisticated GUI programs can be directed textually, with macros or short scripts, and/or have a command-line component for doing that sort of pipe or batch-oriented work. Yeah, sometimes there's functionality stuck behind a button or menu select which I want exposed in a more textual way, in macOS that's when you break out Automator, Alfred, or Hammerspoon (the only one I've ever used fwiw), Linux and Windows have their own equivalents. I don't think the distinction you're pointing to is nearly so stark or clear-cut as it's often made out to be. Ecosystems converge towards the tasks which are amenable to batching and pipelining being equipped to do so.
      - shadowgovt 3y ago
        But in general, batching and pipelining are done via a text-based interface. Extremely rare is the teachable GUI interaface where there's a point-and-click way to describe the concept "See these five items I clicked? Do that twenty-eight more times with this radio button family swizzled via a linear sweep."
rascul 3y ago
> I think at this point we'd have to punt the POSIX toolchain to get something better; it's hard for me to imagine how we'd build discoverable, conceptually-consistent UX atop what we currently have. Posix could potentially do this. It already has a bit about conventions and could be expanded. Problem is getting things to adhere to it, plus I doubt the posix authors could be convinced to add a lot more to it. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

ceving 3y ago

I think graphical user interfaces are no high standard. They do not compose. How would you express a loop or a recursion in a graphical user interface?

shadowgovt 3y ago
They are a challenge for composition, often. Great for discoverability though, and that doesn't require graphics, just context. There should be a button I can push in my shell that lets me ask "what does the token at cursor mean," and a button that lets me type a plain language search string that wires down to a contextual search (i.e. I'm in the middle of typing out "grep" I should be able to ask "how do I search folders?"). We didn't have the tools to build this when grep was invented; we have them now.
samatman 3y ago
I'm genuinely unsure how to translate your question into, hmm. Anything actually. The snarky answer is "By writing it in source code, in a GUI text editor", a thing I do frequently. But the problem is that I have no idea what you're getting at in the first place, so that's just an attempt to recover some meaning from what you wrote.
- shadowgovt 3y ago
  Shells allow one to pipe around the data flowing from called process to called process in a very smooth and transparent fashion. By and large, GUIs do not. There is no such thing as a universal shell for GUIs, and attempts to layer automation atop the GUI abstraction are generally spotty and unreliable (certainly when compared to CLI and shells). This is both for technical reasons (i.e. it's much easier to clearly delineate the two ends of a pipe than to clearly delineate "I want to click on the red square inside the 'diagram' window inside the drawing app") and for ecosystem reasons (since GUIs aren't thought of as automatable, GUI designers are free to move pieces around version-to-version of software, making it extremely challenging to describe a GUI structurally). I've seen some neat attempts at GUI automation (Sikuli is my favorite) but it's never been a core feature like it is in the CLIs-glued-together-by-shells world.
  - samatman 3y ago
    CLIs are in the modern world a subset of GUI programs which run inside a text-oriented window, and plenty of more sophisticated GUI programs can be directed textually, with macros or short scripts, and/or have a command-line component for doing that sort of pipe or batch-oriented work. Yeah, sometimes there's functionality stuck behind a button or menu select which I want exposed in a more textual way, in macOS that's when you break out Automator, Alfred, or Hammerspoon (the only one I've ever used fwiw), Linux and Windows have their own equivalents. I don't think the distinction you're pointing to is nearly so stark or clear-cut as it's often made out to be. Ecosystems converge towards the tasks which are amenable to batching and pipelining being equipped to do so.
    - shadowgovt 3y ago
      But in general, batching and pipelining are done via a text-based interface. Extremely rare is the teachable GUI interaface where there's a point-and-click way to describe the concept "See these five items I clicked? Do that twenty-eight more times with this radio button family swizzled via a linear sweep."

rascul 3y ago

> I think at this point we'd have to punt the POSIX toolchain to get something better; it's hard for me to imagine how we'd build discoverable, conceptually-consistent UX atop what we currently have. Posix could potentially do this. It already has a bit about conventions and could be expanded. Problem is getting things to adhere to it, plus I doubt the posix authors could be convinced to add a lot more to it. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...