4 ms·

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 s

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.

agsilvio 7y ago
While I can't disagree, we should recognise that this was appealing to early computer scientists.
- seemslegit 7y ago
  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.
fctorial 7y ago
How do you feel about argv?
- seemslegit 7y ago
  What about argv ?
  - fctorial 7y ago
    Argv in 'int main(int argc, char argv)'. CLI is a wrapper for this.
    - seemslegit 7y ago
      What exactly does it "wrap", splitting a single string into an array of strings ?
      - jolmg 7y ago
        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.
olalonde 7y ago
> replacing them with a structured, typed, reflective API Does this better alternative exist?
- seemslegit 7y ago
  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.
  - bigato 7y ago
    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)
    - seemslegit 7y ago
      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
pm215 7y ago
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 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).
- seemslegit 7y ago
  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.

agsilvio 7y ago

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

seemslegit 7y ago
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.

fctorial 7y ago

How do you feel about argv?

seemslegit 7y ago
What about argv ?
- fctorial 7y ago
  Argv in 'int main(int argc, char argv)'. CLI is a wrapper for this.
  - seemslegit 7y ago
    What exactly does it "wrap", splitting a single string into an array of strings ?
    - jolmg 7y ago
      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.

olalonde 7y ago

> replacing them with a structured, typed, reflective API Does this better alternative exist?

seemslegit 7y ago
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.
- bigato 7y ago
  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)
  - seemslegit 7y ago
    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

pm215 7y ago

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 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).

seemslegit 7y ago
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.