3 ms·

> 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 A

> 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?

ceceron 6y ago
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.
- arogozhnikov 6y ago
  > API != User Interface. API = Programming Interface. That's where we should start, but the other way around. Why do you keep trying to replace programming interfaces with bash calls? Any example when calling cli compared to proposed alternative makes any difference to your spouse?
  - ceceron 6y ago
    Mostly because user interface is meant to expose the common tasks to the user vs API which is supposed to give a low level control. curl is a good example, as a tool is fairly accessible, but as the library it gives control on all the aspects of connection, requiring much more knowledge/skill from the programmer. Not every user has this kind of knowledge, but still may want to use curl to do quick HTTP requests. User != Programmer Also, "bash calls" are cool - shell is a great tool to compose many diverse tools written in different programming languages. If all the tools were just configurable via writing code in their implementation language: 1) you would have to know all the programming languages 2) you would have to somehow input the code, parameters are just shorter than code

ceceron 6y ago

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.

arogozhnikov 6y ago
> API != User Interface. API = Programming Interface. That's where we should start, but the other way around. Why do you keep trying to replace programming interfaces with bash calls? Any example when calling cli compared to proposed alternative makes any difference to your spouse?
- ceceron 6y ago
  Mostly because user interface is meant to expose the common tasks to the user vs API which is supposed to give a low level control. curl is a good example, as a tool is fairly accessible, but as the library it gives control on all the aspects of connection, requiring much more knowledge/skill from the programmer. Not every user has this kind of knowledge, but still may want to use curl to do quick HTTP requests. User != Programmer Also, "bash calls" are cool - shell is a great tool to compose many diverse tools written in different programming languages. If all the tools were just configurable via writing code in their implementation language: 1) you would have to know all the programming languages 2) you would have to somehow input the code, parameters are just shorter than code