That being said, most CLIs don't make an effort to enhance discoverability, which makes the argument still valid, but a little unfair. Traditionally, the main argument against CLIs is the lack of discoverability that GUIs afford, which is a very valid point. Great CLIs would have been preferable on many fronts. But we had mediocre CLIs and decent GUIs, so it's only natural that it went that way. I am a staunch supporter of the idea that while GUIs became mainstream and CLIs were relegated to a niche position, it should have been the opposite. Some GUIs are extremely usable, some aren't some CLIs are extremely usable, some aren't. On the usability scale, there isn't "CLI apps" on one end and "GUI apps" on the other. If you're going to do one, then a CLI is much, much preferable. Ideally you'd have a well designed CLI for the users who want it & scripting, and a well designed GUI - but let's face it, doing both is a huge drain of time. And of course it enables scripting to a level that GUIs just can't compare to.
It is much more friendly to users with vision or motor impairments: any font and any color scheme can be applied, any method of text input can be used, text readers behave in a much more predictable manner, etc. When well executed, a CLI is insanely superior to a GUI on many fronts (with a few exceptions, naturally, such as image/video editing), and more respectful of the users. As a result the vast majority of CLIs are inspired from programs that are decades old, and in which no thought was given to the interface, thus perpetuating the cycle. It can be done, although it takes a lot of effort to do well- and a lot of the developers who write CLIs* have very few notions of HCI design.
The engineering world would be a much better place if more people built beautiful, easy to use command line apps > The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. (Of course, some of the built-in actions let you run AppleScript or any shell language programs.) OS X's Automator is a really great glimpse of how that could be done in an entirely GUI fashion, but it also shows the limitations of such an approach - most of which aren't in Automator itself, but the very fact that applications need to be written to support it. For GUI programs to be automated they have to provide a scripting API much more complicated than just an input and output stream - and then, of course, you need a scripting language to bind them. I think it's the second part of your statement about automating tasks where CLIs really have the advantage. There's a lot of research out there that provides a lot of evidence that GUIs in general aren't slow, assuming they're well-designed they feel slower to people used to CLIs and keyboard-driven interfaces, but when you actually measure objectively with a stopwatch the results tend to favor GUIs. Personally I loathe having to use any sort of GUI because in general its slow and I cannot as easily automate tasks to customize my workflow. You could then return a machine-friendly serialisation of that in command server mode. If you were following this approach from the beginning, you would probably structure your CLI so that commands emit output in some structured form (eg a tree of named, typed values, or a table of named, typed columns), which is then rendered to the console somehow. The one real let-down is that the output is, AFAIK, the same as Mercurial's interactive output, which means the parent has to parse it with various command-specific regexps.
#Cakebrew no valid shell code
So, it's good code to integrate with, but exactly as powerful as the CLI. These are the same commands as you would use on the command line (interpreted by the same dispatcher, i believe, so really exactly the same). Communication is a machine-friendly framing protocol which allows the parent to execute Mercurial commands. This lets a process spawn a sort of daemon version of Mercurial, with which it can communicate via its standard input and output.
Mercurial has an interesting take on this - the command server: With the library approach, it's easier for one to get ahead of the other. It also means that any functionality added to the CLI is also immediately available to the GUI. One advantage of building on top of the CLI rather than via a library is that it enforces the rule that any functionality available in the GUI is also available in the CLI. To some extent, this is what Git's 'plumbing' layer tries to be, although i don't know how successful it is.
I wonder if you can design CLIs that are better to integrate with, though. A typical CLI might make a terrible piece of code to integrate with.
0 kommentar(er)
