Hacker News Reader

Comment by square_usual | Hacker News Reader

I personally don't see the point. If you want a GUI for some commands, why not just get GUI apps which do those things? Why try to bolt a GUI onto a CLI, especially one that works by pasting commands back into a CLI? You're relying on fig to develop UIs for all of your frequently used commands, and if you don't like fig's UIs for certain commands, you're SOL until they let you make your own UIs, and at that point it's basically an OS with an App Store. If you want a productivity boost from eliminating repeated commands, you're better off writing aliases or bash scripts for your personal use, in my opinion.

Side note: I think the title should reflect the name of the service, Fig.

View on HN

I worked on this idea in 2003 [1] and we envisioned it to help a lot with discoverability and consequently learning curve. Our idea was more interactive in that editing in the UI would immediately be reflected in the terminal and vice versa. A power user would just type the whole command from memory but still have the ability to click a checkbox to add that rare/elusive switch. Beginners could do everything in the UI but quickly learn from seeing the command line string being built.

We worked towards automatically generate the UI from man pages (prioritized from examples found online) rather than manually developing each tool. As a student project we did not get very far.

[1] http://www.mi.fu-berlin.de/wiki/pub/SE/ThesisCommandLine/Ski...

This is really interesting! I think that the scalable approach like you proposed in your thesis makes a lot of sense, but comes at some cost to the user experience.

Rather than being 'smart' and automating everything, we want to make developing apps really easy and familiar.

I'm curious what the biggest challenges were for you with the project? Maybe we could build on your research.

It has been a long time, but I think we struggled most with:

- What is the best architecture to enable this? I think we struggled a lot with wanting to hook on the shell level where the commands are managed, the UI client where the user interface would have to be shown and terminal emulation where it is all key strokes and cursors.

Today I believe that this would really need something like the Language Server Protocol being implemented in bash itself. Today we have bash completion scripts, but still not something as comprehensive as needed.

- How to separate everything into reusable blocks? For instance extracting parameters from man pages, storing as generic config files, whether to offer a DSL for designing the UIs, etc. We did not want to be stuck with one particular terminal, such as KDE's Konsole (for which a student did another prototype [1] in German).

[1] https://www.inf.fu-berlin.de/inst/ag-se/theses/QuintelaGarci...

It’s a half step between getting some Terminal functionality without necessarily having to be fluent in the Terminal. I think the idea is for it to be an option expanding choice without having to necessarily seek out a GUI that will provide an interface to all of the functionality you need. If something is missing, well the Terminal is right there.

Given that the service seems to be aimed at developers, I don't see it as being an option for people who aren't "fluent in the Terminal". I don't see any commands they support that necessarily have to be done in the terminal, either, since such things as git, ffmpeg, psql etc have great GUIs available for nearly all use cases. If you're not a developer, you're better off downloading specific apps instead of using fig, and if you're a developer, I don't see how fig helps you over binding your own aliases or writing scripts for specific tasks.

I don’t disagree, on principle I think it is better to know your tools and know them well.

At the same time I too once had to learn my tools, and I can empathize with those that just want to quickly get to work and don’t want to memorize every single command-line option, whether this tool uses one dash or two dashes, or single letters, whole words, was it a capital “A” or a lower case “a” to do the thing I want. Personally I won’t be using fig, but I could see why someone might try it. If it helps new developers learn the command line, or helps them get to the meat of working with code without feeling hindered by what they perceive as this old archaic interface, but they want to learn this thing eventually, there’s probably some value in that.

I'm a developer and I think it'd be useful. I'm semi-fluent (conversational?) when it comes to CLIs, and this looks like a great way to recall stuff for less frequently used commands or edge cases.

Two reasons why I would download this but not a full on GUIs for things:

1. There's a long tail of CLI tools I use just rarely enough that I can't justify downloading a whole application for something. I just don't need to run awk or sed that often. But if you aggregate "all terminal commands I need to Google usage for", then that adds up just enough to download a helper.

2. There are contexts in which I can't use a GUI. For example, sometimes I need to SSH into a headless server and update a Git repo or do something with sed and awk on a giant pile of logs that I don't want to transfer to my local machine.

(updated the title)

It's interesting to see a hybrid of a console and a GUI. For me I can see usefulness beyond a man page or Google search to see what flags are available for a command and then select flags. Plus there's benefit for users who are new to a terminal. I think we'll see more terminal/GUI hybrids like this (the Darklang "canvas" is an example).

> If you want a GUI for some commands, why not just get GUI apps which do those things? Why try to bolt a GUI onto a CLI, especially one that works by pasting commands back into a CLI?

Having both provides a smooth skill ramp for users. They can start using the GUI and over time they learn the analogous command line interface.

A GUI is also superior for discoverability compared to a command line interface even for experienced users.

The value for me has been the ability to easily bounce back and forth between levels of abstraction. Sometimes you need the granularity the shell provides, but other times it's nice to lean back on a more opinionated workflow. Sort of like the difference between deploying with Heroku versus managing everything with Kubernetes.

Also, Fig is entirely extensible/customizable. This is probably the part I'm most excited about: anyone can build their own apps. All of the example apps on our site are written with the same API that is exposed to developers. (https://withfig.com/docs)

Reply on news.ycombinator.com