3 ms·

Wow, HN is really harsh on the idea of merging CLIs and GUIs... I think that merging CLIs and GUIs have a great potential. GUIs are superior than CLIs on inte

Wow, HN is really harsh on the idea of merging CLIs and GUIs... I think that merging CLIs and GUIs have a great potential. GUIs are superior than CLIs on interaction because it gives context of the current state and visual cues. (And no, TUIs aren't CLIs nor are they better than GUIs.) However users still use CLIs - the biggest advantage that CLIs have is that it allows various programs interact with each other, e.g. via piping. That's why we have CLI programs that's sole purposes that are communicating with GUI programs, for example almost every programmer's text editor ships with a binary that can i.e. reading from stdin, opening an temporary file, and spitting out to stdin (or at least gives the capability of doing that) so that we can use it in e.g. moreutils vipe. It seems Fig is an product that allows the reverse, e.g. tying GUIs to CLIs so that people can use git, curl or other CLI programs in a more interaction-friendly way. I think this is has a great potential, if it's rightly executed (i.e. hopefully doesn't use Electron...?) PS: The argument that 'every programmer knows how to use CLI, so this isn't needed' is just proving the point - programmers deserve better than an plain-text 1970-era interaction, yet we have to use the Terminal daily to accomplish something.

egwor 6y ago
I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI always plays catch up (and no one is interested in keeping the GUI up to date). I think the example for this was the wget gui. My take on this is that for beginners this is really useful. It can also help show you new options that you might not have been aware of. (Have you read the full man page?)
- pcr910303 6y ago
  > I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI always plays catch up (and no one is interested in keeping the GUI up to date). > I think the example for this was the wget gui. Yeah, that's true, but I think it'll be easier than binding GUI to the CLI. The reason CLIs could get this usefulness was because it mixes up user interaction with it's programming interface (which is ironically what people most hate). If you want to make a CLI program, you almost need to spit out useful information to stdout, which means I can extract info from sed. GUIs are much harsher to extracting information and there are some solutions like AppleScript, but it doesn't fly. Which means, exposing the CLI's capabilities to GUIs are much easier than exposing the GUI's capabilities to CLIs. While Fig isn't taking this route, one could write an man-page parser (like how fish does for it's completion) and expose CLI functionality automatically and increase it's usefulness with human annotations. > My take on this is that for beginners this is really useful. It can also help show you new options that you might not have been aware of. (Have you read the full man page?) Yeah, agreed.
blitmap 6y ago
Lightbulb: GUI applications traditionally exchange data between each other (like CLI piping) by saving to disk or offering data via a drag and drop protocol. I wonder if there would be value in having an application that visually allows you to construct a pipeline from application to application. Something like an application called "Flow" where you drag the 1-window GIMP into Box A, then a photo-cataloguing app into Box B. I could also see this being something doable from a system menu. You see a list of open applications and create a visual linkage/workflow between them. I've also wanted a Wayland compositor feature where you drag data from 1 application to another, and the compositor jumps in to offer how to transform the data between them. Say if App-A only offers MP3s, and App-B only accepts FLAC, the compositor could trigger an app to negotiate transforming/re-encoding that data between apps (and then offer to App-B). I have some bad, contrived examples here.
bitwize 6y ago
> Wow, HN is really harsh on the idea of merging CLIs and GUIs... Maybe it's because the system that got it the most right with the Lisp machine, and nearly all subsequent attempts to reinvent this particular wheel turned out suspiciously square...

egwor 6y ago

I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI always plays catch up (and no one is interested in keeping the GUI up to date). I think the example for this was the wget gui. My take on this is that for beginners this is really useful. It can also help show you new options that you might not have been aware of. (Have you read the full man page?)

pcr910303 6y ago
> I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI always plays catch up (and no one is interested in keeping the GUI up to date). > I think the example for this was the wget gui. Yeah, that's true, but I think it'll be easier than binding GUI to the CLI. The reason CLIs could get this usefulness was because it mixes up user interaction with it's programming interface (which is ironically what people most hate). If you want to make a CLI program, you almost need to spit out useful information to stdout, which means I can extract info from sed. GUIs are much harsher to extracting information and there are some solutions like AppleScript, but it doesn't fly. Which means, exposing the CLI's capabilities to GUIs are much easier than exposing the GUI's capabilities to CLIs. While Fig isn't taking this route, one could write an man-page parser (like how fish does for it's completion) and expose CLI functionality automatically and increase it's usefulness with human annotations. > My take on this is that for beginners this is really useful. It can also help show you new options that you might not have been aware of. (Have you read the full man page?) Yeah, agreed.

blitmap 6y ago

Lightbulb: GUI applications traditionally exchange data between each other (like CLI piping) by saving to disk or offering data via a drag and drop protocol. I wonder if there would be value in having an application that visually allows you to construct a pipeline from application to application. Something like an application called "Flow" where you drag the 1-window GIMP into Box A, then a photo-cataloguing app into Box B. I could also see this being something doable from a system menu. You see a list of open applications and create a visual linkage/workflow between them. I've also wanted a Wayland compositor feature where you drag data from 1 application to another, and the compositor jumps in to offer how to transform the data between them. Say if App-A only offers MP3s, and App-B only accepts FLAC, the compositor could trigger an app to negotiate transforming/re-encoding that data between apps (and then offer to App-B). I have some bad, contrived examples here.

bitwize 6y ago

> Wow, HN is really harsh on the idea of merging CLIs and GUIs... Maybe it's because the system that got it the most right with the Lisp machine, and nearly all subsequent attempts to reinvent this particular wheel turned out suspiciously square...