Hacker News Reader

Comment by seemslegit | Hacker News Reader

Command line options are a terrible surface for usability and more importantly, discoverability. We are at least two decades overdue for replacing them with a structured, typed, reflective API and yet every generation of hackers persists to cargo-cult the cli utility, taking pride in remembering copious minutia as if they were wizzards in command of arcane incantations.

View on HN

The lack of discovery is not inherent in a command line system. The usual counter-example is something like TOPS-20 https://www.bourguet.org/v2/pdp10/users/chap2#sec_2 where the command line system was built such that for every command you could interactively in the middle of typing your command line get help about what the possible options were, what the argument for the option you'd just typed was, etc (and this was built in to the system and commands, not a half-baked add-on like bash tab-completion).

Didn't mean to imply that it was inherent, see the comment about powershell bellow - just that that this is the standard we unfortunately came to accept as adequate.

> replacing them with a structured, typed, reflective API

Does this better alternative exist?

No, or it wouldn't have been overdue. Microsoft powershell is probably the closest thing I can think of, which in turn is powered by the .NET/CLR type system.

and do you find powershell to be a simpler alternative? i recently had to look into a 100 or so lines powershell script and it felt crazily hard to read. Good thing I had access to the guy who wrote it so that he just told me what it was supposed to do (he gave up explaining the script)

Yes the powershell language itself is a poorly thought-out hack but using shell scripting for non-trivial tasks is a related but different problem that has to do more with a (thankfully narrowing !) skillset gap between devops/IT people and software developers. So just like a 100 or so line bash script would probably be better off written in python so would a 100 line PS script be better done in any .NET language and exposed as a cmdlet

While I can't disagree, we should recognise that this was appealing to early computer scientists.

We very much do, at least in their hats as hackers (true computer scientists never cared much about actually using computers) there was a point where an online command prompt (one you could edit in real time, as opposed to having to put in a new punch card etc.) was state of the art of interactivity and software interoperability was defined on the level of word sizes and hardware registers, but we can and should move on from that.

How do you feel about argv?

What about argv ?

Argv in 'int main(int argc, char argv)'. CLI is a wrapper for this.

What exactly does it "wrap", splitting a single string into an array of strings ?

If you don't know, when you run `echo -n foo bar`, the shell splits that according to its syntax and runs `echo` with the arguments, `-n`, `foo`, and `bar`. The array of those 4 strings is argv.

To better expand on what fctorial is probably trying to say, argv is a simple list of strings. Plain text is a nice common ground among the myriad of programming languages that executables can be written in. In order replace options with "a structured, typed, reflective API", argv could no longer be a simple list of strings. There would have to be a common typesystem among all programming languages. It wouldn't just be needed for the understanding of argv, but also for the output, since the output of programs is used to feed the arguments of other programs. This puts heavy restrictions on the liberty programming languages can take in defining their own typesystems while retaining compatibility with such an inter-program typesystem.

This isn't to say that it can't be done, but I'm fairly certain it would suck on multiple fronts. You might be able to gain some things, but you'd certainly be giving away others.

EDIT: I don't want to spend too much time expanding what you'd be giving away, but to start

1) Having the common ground be plain text means that you get 1 form of output that can be used both for human and for machines to read. The programmer might not even intend for their output to be used by other programs, but it will always be trivial to do so. You can propose that they could have 2 forms of outputs, one plain text for humans and one typed for machines, but there would be no guarantee that they would have the same information. It's likely that one form will miss information that the other has, and you'd be left with humans reading output meant for machines or machines reading output meant for humans, so you gain nothing.

2) Less brevity. You complained about options being too detailed ("remembering copious minutia"), but that's because they're meant for interactive use. This is not a problem about the interface being untyped. It's about the interface optimizing for being quick to use. This would either also arise with a typed interface (although more difficultly so) or the CLI would simply be more tedious to use. No win there.

3) It would be more inconvenient to use interactively. For example, if you want to differenciate between a number 5 and a string "5", you're going to have to add syntax, like the quotes I used in this sentence. You can see the inconvenience by setting you shell to be something like python, for example. There would be too much syntax for interactive use.

>If you don't know, when you run `echo -n foo bar`, the shell splits that according to its syntax and runs `echo` with the arguments, `-n`, `foo`, and `bar`. The array of those 4 strings is argv.

So it does, albeit a better example of the shell doing something nontrivial would be replacing file patterns with filenames, but it doesn't help since my program could be expecting a list of urls instead and has no standardized way to tell the shell this.

>To better expand on what fctorial is probably trying to say, argv is a simple list of strings. Plain text is a nice common ground among the myriad of programming languages that executables can be written in. In order replace options with "a structured, typed, reflective API", argv could no longer be a simple list of strings. There would have to be a common typesystem among all programming languages. It wouldn't just be needed for the understanding of argv, but also for the output, since the output of programs is used to feed the arguments of other programs. This puts heavy restrictions on the liberty programming languages can take in defining their own typesystems while retaining compatibility with such an inter-program typesystem.

Yes, a language-agnostic reflective type system with a shell and supporting language tools, it's a pretty big implementation and coordination effort and an even greater one to retroactively describe the command line semantics of existing commands so not holding my breath here.

>Besides that, it would be more inconvenient to use interactively. For example, if you want to differentiate between a number 5 and a string "5", you're going to have to add syntax, like the quotes I used in this sentence. You can see the inconvenience by setting you shell to be something like python, for example. There would be too much syntax for interactive use.

A matter of preference I suppose as I have been using jupyter/ipython for all "shell" tasks for quite a while.

Brevity is a particularly false saving here if you factor in the time it takes to lookup documentation on something you don't use just often enough to have its command line options sit in your brains L1 cache.

> the time it takes to lookup documentation on something you don't use just often enough

Well, if I don't use it often, I'm not going to be looking at the documentation often. However, when I do, we're talking about the time it takes to type `man foo<enter>/bar<enter>`, where bar can be `keyword` or `--option\b`. That doesn't even take 30 secs.

thirty seconds and a context switch to a man window is a lifetime, compare with an environment where I just type utiltiy.<tab> autocomplete to 'option', have an inline documentation displayed under the line and a seamless choice box that allows me to choose from several valid values for that option while displaying inline documentation for what each means.

I don't feel that kind of friction with man, but ok. That environment you describe is also common. Though I don't use it, in zsh, if I hit tab, I get that menu with inline documentation you describe. What are you arguing for anyway?

that argv doesn't cut it ?

With that comment about a completion system with inline documentation? How does argv not cut it when zsh does what you described?

Because it's still crude and unstructured - my program still has to operate on an array of strings, and I need to author zsh completion and matching voodoo have it distributed and do the same for everyone's shell of choice whereas I would like to be able to export a struct definition and have my program receive it populated with user input instead of argv

Isn't this what PowerShell does? Makes the pipes pass .NET objects around instead of plain text?

Reply on news.ycombinator.com