4 ms·

I feel like from a design and architecture point of view, building an application with the command line as a first class citizen will ensure that the applicatio

by xmprt 5y ago

I feel like from a design and architecture point of view, building an application with the command line as a first class citizen will ensure that the application is well designed.

stult 5y ago
It ensures separation of concerns is at least minimally applied in order to support two separate presentation layers (GUI & CLI). CLIs are also much more testable in general, so usually it’s easier to write e2e tests if a CLI is present. It might not cover 100% of the code because it doesn’t test the GUI, but does often get you something substantial like 90% of the way there.
- bopbeepboop 5y ago
  It depends on the application, but CLIs can make testing GUIs easier in two ways: - you can test the rendering layer in isolation by using the GUI to display two pieces of information manipulated by the CLI and comparing the renders, eg blank screen -> add some object. - you can comparison test the GUI, eg pressing button X produces the same result as CLI option Y. Properly testing a GUI requires having an internal CLI, in places I’ve worked — eg, app companies.
p2t2p 5y ago
Have you ever run `rm -f important_doc.txt` instead of intended `rm -f important_doc copy.txt`? It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used. Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.
- linspace 5y ago
  > Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover. You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again
  - renox 5y ago
    A copy of the repo really? I just check in everything in a new commit then write the SHA1 somewhere.
    - Sophira 5y ago
      The point of taking a copy of the repo is that you don't have to use git itself to get back to a known state, which is important when it's a tool that you're experimenting with and you're not sure on its use. There's also a psychological element to it. If you can verify for yourself that the repo can't possibly contain anything that would mess you up after an earlier mistake, it's much easier to do things than if you have to worry about using the wrong branch name when you don't know how to delete branches, for example.
  - mst 5y ago
    "cp -a" was definitely a huge boon to learning git. Fear-free experimentation is a wonderful thing.
- marcosdumay 5y ago
  Yeah, user facing filesystems should be change-based, and require elevated permissions to permanently delete data. The problem is that filesystems don't get enough love. There are plenty of more fundamental problems that aren't going anywhere, so do not expect this to change.
- ascagnel_ 5y ago
  I totally agree, as long as that interface gives users knowledge as to how it forgives the user. I use a Mac for work, and one of the first things I did was to alias `rm` to the utility `trash`[0] -- instead of immediately marking the bytes as free like `rm` does, it'll move the file(s) to the system's trash can. [0]: https://hasseg.org/trash/ https://hasseg.org/trash/
codr7 5y ago
It implies that the application is made up of commands, which leads to a healthy separation of concerns.

by xmprt 5y ago

I feel like from a design and architecture point of view, building an application with the command line as a first class citizen will ensure that the application is well designed.

stult 5y ago

It ensures separation of concerns is at least minimally applied in order to support two separate presentation layers (GUI & CLI). CLIs are also much more testable in general, so usually it’s easier to write e2e tests if a CLI is present. It might not cover 100% of the code because it doesn’t test the GUI, but does often get you something substantial like 90% of the way there.

bopbeepboop 5y ago
It depends on the application, but CLIs can make testing GUIs easier in two ways: - you can test the rendering layer in isolation by using the GUI to display two pieces of information manipulated by the CLI and comparing the renders, eg blank screen -> add some object. - you can comparison test the GUI, eg pressing button X produces the same result as CLI option Y. Properly testing a GUI requires having an internal CLI, in places I’ve worked — eg, app companies.

p2t2p 5y ago

Have you ever run `rm -f important_doc.txt` instead of intended `rm -f important_doc copy.txt`? It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used. Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.

linspace 5y ago
> Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover. You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again
- renox 5y ago
  A copy of the repo really? I just check in everything in a new commit then write the SHA1 somewhere.
  - Sophira 5y ago
    The point of taking a copy of the repo is that you don't have to use git itself to get back to a known state, which is important when it's a tool that you're experimenting with and you're not sure on its use. There's also a psychological element to it. If you can verify for yourself that the repo can't possibly contain anything that would mess you up after an earlier mistake, it's much easier to do things than if you have to worry about using the wrong branch name when you don't know how to delete branches, for example.
- mst 5y ago
  "cp -a" was definitely a huge boon to learning git. Fear-free experimentation is a wonderful thing.
marcosdumay 5y ago
Yeah, user facing filesystems should be change-based, and require elevated permissions to permanently delete data. The problem is that filesystems don't get enough love. There are plenty of more fundamental problems that aren't going anywhere, so do not expect this to change.
ascagnel_ 5y ago
I totally agree, as long as that interface gives users knowledge as to how it forgives the user. I use a Mac for work, and one of the first things I did was to alias `rm` to the utility `trash`[0] -- instead of immediately marking the bytes as free like `rm` does, it'll move the file(s) to the system's trash can. [0]: https://hasseg.org/trash/ https://hasseg.org/trash/

codr7 5y ago

It implies that the application is made up of commands, which leads to a healthy separation of concerns.