GUI vs. CLI - the last battle

Real programmers believe that nothing better than the command-line interface has yet been invented and will never be invented, because there is nowhere better. Naturally, I want to argue.

To better understand each other, let's talk about abstract oranges. Imagine AutoCAD if you have heard or tried to. You can Illustrator or CorelDro, anything far from programming to abstract and reason impartially. Why can't they work in the console?


Fig. 1. Abstract interface in vacuum.
')
First: you need to have a general picture of what is happening. Writing a command (get-lines) and getting an honest list (((0 12) (5 12)) ...) inconvenient for a person. Trying to understand the current situation with the help of commands is to exchange notes through the keyhole about how the wind smells and how the music sounds (by expressiveness) and pure bureaucracy by the method when the certificate is issued only by a correctly written statement, you will find out your mistake only after filing, and in the future the application will have to write again and again. And, yes, to find out what requests you can submit at all, you need to make a separate request.

One glance at the overall picture can immediately clarify everything for a person, whereas one should think about requests, interpret results (each answer is its own projection of information, which does not contribute to the development of a mental model or the development of a habit). On a sufficiently capacious scheme, different people can see each his own - what is now interesting. In short, it is better to see once.

Second: direct interaction. In the graphical interface, a person can move objects themselves, while in the console, he needs to solve the equation "which variable and how to change it so that the solution changes as I want." It operates in one space, the problem is in another, the translation rules are formalized in one direction (command → task), and the inverse problem must be solved. It feels like roughly how to prototype a site layout right away in a htmle. Returning to the bananas, I can take the end of the segment and drag it to the end of the other segment (connect). I see what needs to be done, and I do exactly that.

It may seem to someone that, on the contrary, the interface in the style of request-response is more natural for a person - after all, this is how we build a dialogue with people in life. Count the number of actions and compare. In the hypothetical console, I:

1. It should somehow indicate which segment to move, i.e. compose and check the request for the search for a segment by a unique feature; a sign also to be invented;
2. similarly, find the end of the second segment;
3. give the command and give it the results of the previous commands;
4. somehow make sure that what happened is needed, and only what is needed;
5. make sure that this is what I wanted.

I bet that nothing of what I wrote is incomprehensible without an example. Take git as one of the most striking examples of inappropriate use of the command line interface, for which, however, many seemingly intelligent people are completely in vain ready to break spears. So I came to work in the morning and went to the repository folder. What's happening? What did I stop at? What branch am I in? Did I commit everything yesterday? Have you started? Did it pop up? After the pool, how did my commits stick sideways? What is the repository structure? In the console, these are all separate commands. In order for me to get involved in work, I need to type, start and collect the results together in my head, about seven spells. This is for clarity and overall picture. The only thing is that the git draws graphically the repository structure (well, pseudographically - but this is no longer a console, this is a poor gui).


Fig. 2. Output from git log --graph --pretty=oneline --abbrev-commit . Will you play from memory?

About direct interaction is also interesting. Looking at the tree in gitk is not a big problem to understand what is happening now, even in the middle of a complex merge or some other tricky transformation. But to translate it into teams is already more difficult. For example, I understand that it is necessary to transfer all changesets to another branch starting from this commit. But which team? At the moment there are five of them, all with their own characteristics, they depend on where I am and where I want to go, and usually they do what I need, that is, they need to be combined. Every time I solve this riddle with difficulty (shame on me, I could even memorize by my age), terribly struggling with my impotence (I understand everything, but I can’t say) and quite rightly melt my anger for the quest created from scratch.

But even if the commands are made more straightforward, the problem will still remain - in one window I will have to look at the repository tree and slowly rewrite the revision hashes to another. That is, again it is unclear what the bonus is.

And now about the good. Flexibility. Power. Dumplings. I'm not a fool and will not argue with the fact that bash + unix utils is a powerful bundle. Only enthusiasm here is usually associated with the fact that bash is such a REPL script language for a file system that its interface successfully complements (see, for example, how it is built into mc or Far, and yes, these are not command line interfaces). Having a script language with a REPL in the program is good, this makes the interface suitable for more complex tasks. (The erudite reader knows that there is a Lisp console in AutoCAD, and all the terrible things listed in it can be done - search for objects, move lines). But for the reasons described above, remember that this is an exchange of usability for flexibility, which is why only the simplest utility functions are possible in cli. And this is precisely the essence and genius of the graphical interface.


Fig. 3. Command mode AutoCAD.