CLIs are reified UIs (2017) • Hacker News Board

Re: CLIs are reified UIs (2017)

#111

Post by teyc » Thu, May 28, 2020, 11:35 AM UTC

nerdponx wrote: post #27

fermienrico wrote: post #3

The biggest problem with CLI is discoverability as the article points out. Looking at Docker CLI, there are like a bazillion commands and it takes forever to read through the docs to find out what exactly to use. Furthermore, there are some commands that depend on the others being there - that breaks the composability. Back to discoverability, is there a way to make CLI "more discoverable"? Reading the man page doesn…

is there a way to make CLI "more discoverable" I've thought about this a lot. The answer, I think, is to have a "reverse index" of tasks that you can do with the tool and their corresponding commands or recipes. For example, man pages are typically organized alphabetically by option or subcommand. I'm envisioning a section of documentation - maybe a separate man page or just something on a website - that looks like t…

Powershell has a common language, common help system, common logging framework. It's a very nicely done project.

You can

    Get-Help Update-ItemProperty -Example

to get some samples.

It is introspectable, so command line completion of argument parameters just work.

I even saw web based and windows based gui that can probe any powershell command and provide a rudimentary UI with field level help.

You can even find the relevant commands e.g.

    Get-Command -Noun PSDrive

gets you all the commands that can act on a PSDrive object.

Re: CLIs are reified UIs (2017)

#112

Post by rcxdude » Thu, May 28, 2020, 11:48 AM UTC

wrs wrote: post #61

I've used at least a few GUIs that automatically generated a log of commands corresponding to your GUI actions, which you could observe, replay, or copy into a script. The only one I can think of right now is the Active Directory Administrative Center [0], with its "history viewer" that shows the PowerShell command equivalent of everything you do. I think another one was SQL-related. Anyway, this is one way you can "…

Blender does this, and I've also used an FPGA IDE which had the same feature. I think it's pretty useful, but both have holes where there's actions in the GUI which don't work properly in the script.

Re: CLIs are reified UIs (2017)

#113

Post by SomeoneFromCA » Thu, May 28, 2020, 11:55 AM UTC

kitotik wrote: post #11

fermienrico wrote: post #3

The biggest problem with CLI is discoverability as the article points out. Looking at Docker CLI, there are like a bazillion commands and it takes forever to read through the docs to find out what exactly to use. Furthermore, there are some commands that depend on the others being there - that breaks the composability. Back to discoverability, is there a way to make CLI "more discoverable"? Reading the man page doesn…

Really good autocompletion replete with helper/explanatory text can help a lot with CLI discoverability.

You may find "fish" shell interesting.

Re: CLIs are reified UIs (2017)

#114

Post by shric » Thu, May 28, 2020, 12:38 PM UTC

I really wish more CLIs would have a, ideally standard, flag to output something structured and easily parsable. One of the biggest arguments for CLIs is their composability, which is true for canonical examples like | sort | uniq -c | sort -nr | head -10 etc. However, I find myself constantly having to use awk, sed, cut, etc. far too often. A very much inexhaustive list of things one has to deal with:

- whitespace delimited with fields that contain whitespace.

- tabular lined up data that doesn't actually use tabs, and when a field is too wide, it just pushes the rest of the line over.

- 5,000 different variants of CSV

Of course some things (e.g. kubectl) have json and yaml output options, which can be nicely parsed with jq.

I also found https://github.com/kellyjonbrazil/jc handy, which attempts to convert many commands to json output.

Re: CLIs are reified UIs (2017)

#115

Post by krab » Thu, May 28, 2020, 1:50 PM UTC

FpUser wrote: post #48

CAD and other high end complex packages for example offer combination of command line and GUI at the same time where one can augment the other at many points.

What I liked the most was when a GUI would emit the CLI commands for my actions. It breaks the discoverability barrier significantly. You learn in the GUI but you can switch gradually to the CLI with aliases, functions and loops.

Re: CLIs are reified UIs (2017)

#116

Post by strogonoff » Thu, May 28, 2020, 2:22 PM UTC

zoomablemind wrote: post #50

I always considered GUI as a 'dialog'. That is implying a conversation between user and program. Meanwhile, CLI, especially in scripted use, appear as monologs. Of course, CLI can also show user-prompts, but in repeated use they will likely get scripted. This turns CLI into a command monolog: "I described everything needed", where program declares: "Here's the best I could do for that." On the other hand, a dialog as…

To me CLI feels much more like a verbal dialog with a person, while many GUIs give a feel of poking and pointing. Might be subjective—I also much prefer audio calls over video, for example.

Re: CLIs are reified UIs (2017)

#117

Post by xerxesaa » Thu, May 28, 2020, 4:07 PM UTC

fermienrico wrote: post #3

The biggest problem with CLI is discoverability as the article points out. Looking at Docker CLI, there are like a bazillion commands and it takes forever to read through the docs to find out what exactly to use. Furthermore, there are some commands that depend on the others being there - that breaks the composability. Back to discoverability, is there a way to make CLI "more discoverable"? Reading the man page doesn…

I personally like using the "tldr" command line tool. It gives a short overview of the most common commands.

https://github.com/tldr-pages/tldr/

Re: CLIs are reified UIs (2017)

#118

Post by cvlasdkv » Thu, May 28, 2020, 4:28 PM UTC

cuddlybacon wrote: post #39

crazygringo wrote: post #35

Earlier quoted context omitted.

> GUIs are deeply nested. And context sensitive so it may not even be possible to see actions until certain condition is met. This is a feature, not a bug. For me, browsing 20 pages of --help or man is a discoverability nightmare. I don't want to wade through arcane option after arcane argument. The GUI gives me a well-organized top-level understanding of the program: organized menus, and organized panes (panels/pale…

> This is a feature, not a bug. Seconded. The hard part of CLIs is discovering what is possible in the current context. You can almost take for granted that a GUI will do this for you. CLI not only won't, but will often fail to discuss this in the man page. While there are exceptions (eg tmux), I find most man pages are written for someone who already knows how the command works but forgot a particular detail.

> While there are exceptions (eg tmux), I find most man pages are written for someone who already knows how the command works but forgot a particular detail.

Isn't that a function of how much work is put into man pages vs. the GUI? I'd be hesitant to claim that if you took the same number of hours in writing a GUI and put it into writing better documentation that we'd be in the same place we often are with poorly documented tooling.

Re: CLIs are reified UIs (2017)

#119

Post by nerdponx » Thu, May 28, 2020, 7:05 PM UTC

teyc wrote: post #111

nerdponx wrote: post #27

Earlier quoted context omitted.

is there a way to make CLI "more discoverable" I've thought about this a lot. The answer, I think, is to have a "reverse index" of tasks that you can do with the tool and their corresponding commands or recipes. For example, man pages are typically organized alphabetically by option or subcommand. I'm envisioning a section of documentation - maybe a separate man page or just something on a website - that looks like t…

Powershell has a common language, common help system, common logging framework. It's a very nicely done project. You can Get-Help Update-ItemProperty -Example to get some samples. It is introspectable, so command line completion of argument parameters just work. I even saw web based and windows based gui that can probe any powershell command and provide a rudimentary UI with field level help. You can even find the re…

This is really useful, thanks for that. Unfortunately I can't bring myself to use Powershell because of the sheer verbosity of the command line (might as well just use Python, in my opinion), but I really like a lot of their design choices.

Re: CLIs are reified UIs (2017)

#120

Post by camgunz » Thu, May 28, 2020, 7:29 PM UTC

hhas01 wrote: post #93

camgunz wrote: post #91

Earlier quoted context omitted.

CLIs and GUIs aren’t an either/or proposition. They each implement very different paradigms; OP goes over them pretty reasonably. You’re not supposed to discover a CLI; you’re either supposed to remember the 4 things you do all the time (see git) or script it and build your own interface/program (see coreutils or stuff like troff). It’s an entirely different UI. Arguing that CLIs aren’t discoverable misses the point…

“CLIs shouldn’t be discoverable because they’re not supposed to be discoverable.” Imagine if we applied the same defeatist tautological thinking to our other written materials: books wouldn’t have TOCs or indexes, the Web wouldn’t have search engines, and so on. 10,000 years of the written word, yet nothing is learnt. SMH. Maybe if text-based interfaces did provide good, safe discovery they wouldn’t have been beaten…

It's not a tautology, it's choosing how something works. Try it with other things:

"Guitars shouldn't have reeds because they're not supposed to have reeds"

"Cars shouldn't have pitch controls because they're not supposed to have pitch controls"

> Maybe if text-based interfaces did provide good, safe discovery they wouldn’t have been beaten into a cocked hat by GUIs for 99% of users.

This isn't so much CLI vs. GUI but interactive vs. non-interactive. Think CLI vs. TUI. Then (hopefully, I guess) you'll realize that it's a deliberate difference in paradigm vs. one or the other being superior.

Indeed, this is the entire point of OP. Reification of the interaction means making that interaction first-class, and CLIs do this by making the interaction the invocation, which you can then manipulate. You can't (mostly, w/o some kind of session scripting tool or w/e) do that in a GUI or TUI.

Kind of a lot of heated discussion about this but, it doesn't seem like it's that big a deal.