The premise is not worth criticizing. I wonder what his motivation was for writing this nonsense?
Don't write command-line interfaces (and how to write if you have to)
11–20 of 25 posts
Re: Don't write command-line interfaces (and how to write if you have to)
#12This... isn't persuasive. I'm genuinely struggling to find a deeper critique than that. Perhaps if there were examples of all the confident statements? But they're just terse declarative sentences, all I could say is "nuh uh!"
The "better" examples using inline code made my head spin.
Re: Don't write command-line interfaces (and how to write if you have to)
#13> How do you test CLI? I do not understand this. Has the author used diff or stdin/stdout redirection? Testing CLI is trivial in comparison to testing a GUI or another kind of interface; it is all text and so can easily be compared against a correct result. CLIs are not meant for every task, but one of their core advantages is ease of automation and testing.
It is easy only if you write CLI utility (or somewhat very light-weight).
Imagine you write ASR system (from CLI input to output - week(s) of training, requires several servers). Mind telling me more about using diff/stdin/stdout in this case?
Well, forget ASR, take any ML system.
Re: Don't write command-line interfaces (and how to write if you have to)
#14This... isn't persuasive. I'm genuinely struggling to find a deeper critique than that. Perhaps if there were examples of all the confident statements? But they're just terse declarative sentences, all I could say is "nuh uh!"
The "better" examples using inline code made my head spin.
It looks new - but is it any more complicated if after all that's what your call maps to?
Re: Don't write command-line interfaces (and how to write if you have to)
#15Strong disagree. Any system worth keeping around should be a library (or family of libraries) which have a CLI fronting it that serves to pass parameters to it just as you might any other way (such as through some other program or REST API or GUI). Agree the CLI "shell" around the system should not have separate logic, but should report back logic faults from within the library.
> Agree the CLI "shell" around the system should not have separate logic
that was the main point.
> should report back logic faults from within the library
And I suggest validating parameters passed to functions.
So what's this you disagree with?
Re: Don't write command-line interfaces (and how to write if you have to)
#16I think this is trying to say you shouldn't build CLI parsing logic into your core functionality, and this makes sense. Core functionality should be in functions, classes, etc. and a CLI utility can be separately written or synthesized that imports that library, and anything wanting to implement a different interface can do the same. Isn't that the way it's normally done? Real world example is libcurl and curl comman…
+1 for reading post
Re: Don't write command-line interfaces (and how to write if you have to)
#17> How do you test CLI? I do not understand this. Has the author used diff or stdin/stdout redirection? Testing CLI is trivial in comparison to testing a GUI or another kind of interface; it is all text and so can easily be compared against a correct result. CLIs are not meant for every task, but one of their core advantages is ease of automation and testing.
ok, I understand now my question got misinterpreted, I'll rewrite that.
CLI parsing (mapping to real calls) may have bugs. How do you test this?
Both options suggested eliminate this possibility completely.
> one of their core advantages is ease of automation and testing.
Any example when suggested options are any worse in this sense?
Re: Don't write command-line interfaces (and how to write if you have to)
#18> How do you test CLI? I do not understand this. Has the author used diff or stdin/stdout redirection? Testing CLI is trivial in comparison to testing a GUI or another kind of interface; it is all text and so can easily be compared against a correct result. CLIs are not meant for every task, but one of their core advantages is ease of automation and testing.
ok, I understand now my question got misinterpreted, I'll rewrite that. CLI parsing (mapping to real calls) may have bugs. How do you test this? Both options suggested eliminate this possibility completely. > one of their core advantages is ease of automation and testing. Any example when suggested options are any worse in this sense?
I guess our conceptions of CLIs are different. I wasn't thinking of developing complex textual formats that need to be parsed as input to a CLI program, I was thinking more like simple flags like `--do-operation=value` as opposed to a button in a GUI doing the same thing. If you have a function you want to call named foo() it should be pretty easy to just look for a `--foo` flag and run it. The problem becomes trickier if you have to parse some inputs from text. However, most CLIs I've seen for third party services use mostly simple flags, each of which corresponds to some simple operation. They may take an arg or two (e.g. `cli-client --foo 34 --title "Hello"`). If there is a more or less one-to-one mapping between functions and CLI flags, then it should be pretty easy to test. Testing a full-on parser for complex CLI commands is definitely harder, though.
Re: Don't write command-line interfaces (and how to write if you have to)
#19Earlier quoted context omitted.
ok, I understand now my question got misinterpreted, I'll rewrite that. CLI parsing (mapping to real calls) may have bugs. How do you test this? Both options suggested eliminate this possibility completely. > one of their core advantages is ease of automation and testing. Any example when suggested options are any worse in this sense?
I guess our conceptions of CLIs are different. I wasn't thinking of developing complex textual formats that need to be parsed as input to a CLI program, I was thinking more like simple flags like `--do-operation=value` as opposed to a button in a GUI doing the same thing. If you have a function you want to call named foo() it should be pretty easy to just look for a `--foo` flag and run it. The problem becomes tricki…
> then it should be pretty easy to test.
If it is that simple, you can just devote this to package like typer. That's what I point to - don't write it.
I see people somehow read GUI along the lines, while I never even considered that as an option. Added a note and please read completely before commenting
Re: Don't write command-line interfaces (and how to write if you have to)
#20Strong disagree. Any system worth keeping around should be a library (or family of libraries) which have a CLI fronting it that serves to pass parameters to it just as you might any other way (such as through some other program or REST API or GUI). Agree the CLI "shell" around the system should not have separate logic, but should report back logic faults from within the library.
> Agree the CLI "shell" around the system should not have separate logic that was the main point. > should report back logic faults from within the library And I suggest validating parameters passed to functions. So what's this you disagree with?
I share @ezekiel68 feeling. Your solution to replace CLI parameters with code is a terrible idea...
1) CLI support is an additional logic in your program that makes no real work
CLI is a user interface, it does real work as giving user way to interact with your program. It's an interface.
2) Error (exception) handling with CLI is very poor. Another layer of (bad faulty) code is required to make it possible.
Like with any other code. That's why you should to test it (like any other code).
3) Scaling/extending is not as easy compared to programming language APIs (see example in the end)
It's much easier. At least to my wife, who isn't programmer, but can use shell.
4) CLIs are detached from essential code, which in most cases is disadvantage.
What cases?
5) Forcing users to use CLI means: stay away from my code, you’d better not work with it.
Why having CLI would have to force the user to not use the library (if it is intended to be a library, not a stupid tool)
To sum up:
API != User Interface. API = Programming Interface.
Two different goals, two different sets of requirements. You can't just reduce one to another.