Command line interfaces are reified UIs

163 点作者 vanschelven超过 7 年前

25 条评论

jasode超过 7 年前

>There is, after all, no fundamental reason a GUI could not be designed with the goal of reification of interaction in mind; it’s just that it is rarely done in practice.If we have to search for an underlying reason, it's that most GUI interactions by most end users don't need reification and therefore, that code is not put in.If the GUI has obvious needs for reification, the programmers account for it. Two examples that come to mind are computer chess games, and software audio workstations.Many computer users who are comfortable with UNIX command line will nevertheless "move chess pieces" by clicking and dragging the piece from one square to another. However, virtually all chess programs still record the algebraic chessboard notation of each move and the players can see the tally of moves scrolling on the side of the board.The other example has music producers mixing a song. They will adjust the sliders/faders of volume panning and the software will record their moves. It's known in the trade as "mix automation". When the song is played back, the software makes the sliders mimic the same moves. The automation in "reified" into a time graph[1] such that one can move the nodes around to fine tune the movements more precisely than the fingers did in real time.As for other GUI applications like typical business data entry screens, etc... most GUI toolkits like C# Winforms, C++ Qt, HTML buttons, etc do not include a macro recorder in the default event loop. Therefore, to "reify" the GUI in the same fashion as chess programs or the audio software requires grafting data structures and programming extra code to "record" the button presses into a timeline. Programmers won't do this unless there's a customer need for it. (E.g. Photoshop lets you reify the GUI as "actions" for later playback")[1] example yellow line graphs the fader or knob changes: <a href="http://cdm.link/app/uploads/2014/06/logicmixing-640x399.jpg" rel="nofollow">http://cdm.link/app/uploads/2014/06/logicmixing-640x399.jpg</a>

评论 #15622973 未加载

评论 #15620800 未加载

评论 #15620828 未加载

评论 #15623699 未加载

评论 #15621073 未加载

评论 #15620728 未加载

评论 #15620973 未加载

nerdponx超过 7 年前

They reify UIs, but discoverability of functionality can be a real problem. Git, of course, is the classic example, because its "UI" is a hacked-together mess compiled over years and years and features were added piecemeal. But even for green-field CLI tools, it's a problem.The real value of CLI tools is extensibility and scriptability. You don't have to rely on the application developer inserting UI hooks everywhere; you just write a shell script, and in the absolute worst-case scenario use Expect to automate interactive processes. And adding a new subcommand is relatively trivial. The code is typically easy to trace the user input down to the internal machinery. The UI is a very simple function dispatch and argument-passing mechanism. There are no widgets to worry about, no switches or boxes to position.Therefore CLI tools will always be beloved by power users and feared by everyone else. If you know exactly what you're doing, they can really speed up your workflow and provide and interface for precise, expressive control and automation. Otherwise, all but the best-designed CLI tools are intimidating and difficult to master. Who can remember all those switches? Having a bunch of labeled buttons laid out in a UI leads to a much lower cognitive load.IMO the real value is in CLI applications that can be embedded in a GUI, but are embedded transparently, in that the GUI can be scripted by simply scripting the underlying CLI. Git (Git GUI, GitHub, Tortoise, Tower, etc), Apt (Aptitude, others), TeX (Tex Live Manager, kinda), and others have good interfaces along these lines, but we're definitely in need of a good CLI interface for Rsync and Tar. Many CLI wrapper GUIs tend to be opaque and don't expose enough underlying functionality.One standard for history-keeping is the following: If we start with a clean system, and replay all the commands from the history, will we end up with the same system?This is how Lighttable, Photoshop, and other Adobe CS products work. Also the Vim "undo tree" to some extent. It's an excellent feature.

评论 #15620839 未加载

评论 #15620692 未加载

评论 #15624547 未加载

robotresearcher超过 7 年前

> CLIs predate GUIsI'd consider the front panel of physical buttons, switches, knobs and dials of early, pre-teletype computers to be much more like a GUI than a CLI. We circled back around to buttons and sliders, with state display laid out in 2D in ways our brains enjoy.

评论 #15622242 未加载

评论 #15622064 未加载

jernfrost超过 7 年前

I consistently surprises me how many people can't grasp the advantages of both approaches CLI and GUI.For me the key thing about CLI's is the same as the benefit of plain text in the traditional unix style of thinking.When your interface to any functionality is plain text you have the advantage that you can use any number of generic tools to manipulate that interface.One example is how visual programming languages are mostly failures. It doesn't take long before the inherent problems of composing a program in a GUI is made clear. Text is easily malleable.You see this on many levels. You might be in an IDE and need to change a value of multiple settings or duplicate some setting several times, except there is no tool in your IDE to actually do a substitution of values in arbitrary settings or do duplication.However when settings are represented as just plain text, this becomes a trivial matter to solve.One of the reasons I love macOS so much is that from the very beginning of OSX Apple made the interaction between GUI and CLI very smooth. They both have strengths and I am no fundamentalist, and so they should work well together. You see that in how Apple early supported things such as dragging and dropping objects from the GUI into the terminal.app or the "open" command which allowed you to invoke the appropriate GUI tool for a given file type from the CLI.The Plan9 guys probably went furthest in this. They seemed to have woven GUI and CLI thinking tightly together.

lispm超过 7 年前

If you use Symbolics Genera (or the Common Lisp Interface Manager, see for example McCLIM), the GUI interactions will seen as 'gestures' and not as clicks. For example there could be a Select gesture. These gestures then invoke commands. The commands created by mouse gestures will be recorded in the interactor history like a command which has been typed to the interactor. Pointer gestures are : select, describe, delete, menu, edit,Thus one gets a history of commands, which also can be reused, even from mouse gestures. Selecting a command from a menu or direct manipulation usually will lead to a recorded commnand in the interactor. The interactor runs a command loop.

评论 #15621098 未加载

pklausler超过 7 年前

CLIs are (or can/should be) composable. This is what really makes functional programming languages so powerful -- they give you a few connective frameworks, and a box of components that can be glued into them, and one can compose great things from simple things.Or, in other words, "|" in the shell is "." in Haskell (with operands reversed).

评论 #15620691 未加载

评论 #15622488 未加载

stcredzero超过 7 年前

The Morphic framework in Squeak Smalltalk was an excellent example of this idea. Every object essentially had a little REPL+IDE attached to it. The more standard Smalltalks weren't far off from this either. In just one afternoon, one of my coworkers wrote a utility allowing him to command-click anything in the GUI of our app and open a browser and inspector on it. The reason why he did that, is because he sorely missed an even more powerful utility of this type from his Symbolics Lisp days.

digi_owl超过 7 年前

This reminds me of an old osnews article i dug up a while back.<a href="http://www.osnews.com/story/6282/The-Command-Line--The-Best-Newbie-Interface/page1/" rel="nofollow">http://www.osnews.com/story/6282/The-Command-Line--The-Best-...</a>It basically talk about teaching older people to use computers by way of the unix CLI.

colordrops超过 7 年前

Regarding the benefits of CLIs, "reification" is only one benefit of many:Economy:Graphical protocols like X or web standards are much heavier over the wire than text, and are often not suitable for many use cases. There is also economy of movement, moving the hand back and forth from keyboard to mouse or up to the screen to tap.Consistency:Text is a relatively simple data format supported everywhere. Cutting and pasting data with images and formatting, for example, is often a mess or doesn't work.Precision:Mouse (and touch) input is imprecise and frustrating analog experience. Clicking on a specific point requires moving to it and not missing it. Grabbing an edge of a window is the least elegant gesture ever created. Text entry is precise and digital.

评论 #15623891 未加载

berdon超过 7 年前

In case you were wondering:re·i·fymake (something abstract) more concrete or real. "these instincts are, in humans, reified as verbal constructs"

falcor84超过 7 年前

I absolutely agree about the benefits of reification.In addition to creative authoring tools such as Photoshop which others have mentioned, I want to praise Microsoft's SSMS (SQL Server Management Studio). Some years ago, I had spent some time DBA'ing MS SQL Server and really enjoyed that tool. It's an extremely discoverable GUI for managing this very complex DBMS, and before every operation you perform through one of its wizards it would show you the T-SQL command it generated to perform that action, so you could review and/or script it.I wish more sysadmin tools were like that.

kazinator超过 7 年前

"Reification" has a fairly clear meaning in CS: basically, it refers to a situation when some feature in a language is made available as a value that can be "passed around" in the program and used somehow. Closures are a reification of functions and lexical environment; continuations a reification of control flow, etc. Classes can be reified as objects, so that we can receive a class as an argument and ask that class to spin off an object of the type that it represents. The va_list type in C reifies function arguments (at least the trailing ones, of a variadic call) so then they can be passed to another function or functions.We can take as our model of a simple UI the "dialog box", in which a user can prepare some inputs, and then submit. The "dialog box" corresponds to a function with arguments, and the sumbmission is a function call. So of course, in an underlying programming language, the equivalent can be reified as a first class function.Even a relatively unsophisticated textual CLI can "reify" that at least by turning the concept of a "command" into a string value: there can be a variable that can hold a command, which can be passed around, dynamically calculated and altered, and executed.The UI usually has no straightforward equivalent of "generate 100 instances of this dialog box invocation, feeding successive values from this list into the ID field ...". That sort of "reification" can occur with tools that automate the generation of events into the windowing system.Graphical frameworks in which you can make "actor" objects and hook them up are kind of a reification of the GUI.

have_faith超过 7 年前

I use the command line a lot for web dev but wouldn't say I was a real power user.Pain points for me are discoverability and ease of making dangerous mistakes. I can't remember the command for every useful utility and it's very easy to accidentally break lots of things. Great power comes with great responsibility and all that.What tools do you use for auto-complete-ish features on the command line? or anything to generally make using it easier.

评论 #15622408 未加载

评论 #15620928 未加载

TuringTest超过 7 年前

Notebooks a la Jupyter do have all the qualities described in the article in graphical form. In fact any programmable system that allows combining multimedia objects could be shaped as a graphical CLI.That kind of system would have been very hard to make with object oriented programming. But thanks to the recent advances in programming languages supporting asynchronism and composability, we'll see more of them.

jameshart超过 7 年前

Interesting that as an example of the benefits of 'reification' the author gives the ability to copy/paste commands to execute them again.Of course, this interaction with the command interface - that of selecting the previous command, copying it, then pasting it - is not 'reified'. It is executed through the - we may have to admit it - graphical interface through which you are interacting with the command line interface. It's not a purely textual interface, after all, since it includes graphical elements like a cursor.As an experiment, consider that a voice assistant like Alexa or Siri is also effectively a command line interpreter, but that in those cases 'copy paste' is not available so easily. 'Siri, repeat back the last command I gave'?So maybe the interface that is being praised here isn't the command line but rather the graphical interface in which a command-reifying interface is hosted...

评论 #15623230 未加载

评论 #15624359 未加载

jstewartmobile超过 7 年前

What about reification of failure?One supremely nice thing about *nix-style systems is that most programs will barf a number of complaints along the way to failure, while Mac/Windows counterparts typically fail silently or log errors to a mysterious per-app location.

derefr超过 7 年前

I've always wondered why every application doesn't just have a shell console hanging off the bottom of the window, the way browsers do.We've already had a half-assed version for decades, part of nearly every GUI ever (though they're falling out of fashion these days): "status bars." And most OSes also already have a "scripting" mechanism that requires applications to expose a specific "scriptable API" (WSScript requiring ActiveX components on Windows, Automator requiring Apple Events on macOS.)So just combine the two! The OS could have a "status-bar control" that you'd stick onto your main window of your app, which would start as a regular status bar, but have a little disclosure arrow—that would turn it into a full historical log of every previous "status", plus a REPL for entering script (probably with a dropdown to select which of the OS's available "scriptable languages" you're writing in.)If you don't want to muck up your GUI, you could simply detect whether your GUI app has been launched from an interactive terminal (i.e. whether stdin is a PTY) and then provide a regular REPL-like interface on the terminal. A lot of GUI apps already log to stdout in the expectation that developers will be running them from the terminal; why not just add some more interactivity the same way?---I should also mention a third, much less obvious route: Plan9's Acme editor, which isn't so much a "GUI editor" in the normal sense as it is a text buffer with a configurable space of API commands hanging off of it.In Acme, the menu system (and its associated keyboard accelerators) are effectively just another text file that you can tab into and edit. Each thing you write into the menu is just a literal API call. Hitting that menu item will then call that API, passing the selection or the current buffer as necessary. [It's actually even more universal—in Acme, left-click selects and middle-click activates. You can write a command anywhere and then middle-click it. The menu just provides a convenient holding place for middle-click-able text.]Acme has its own internal commands—sort of like Windows PowerShell—but it also allows you to just write regular shell commands into the menu as well. Activating a `wc -l` menu-command will literally just dump the output of `wc -l` into the status bar. Activating `tr A-Z a-z` will literally just tr(1) your selection/buffer into lowercase. Etc.And I fudged a bit: the commands that are "internal" to Acme are just shell commands too. Since we're talking about Plan9, every process has its own environment, so Acme has a set of internal binaries that end up in its own /bin. These little "command" programs just use RPC to send commands to the current Acme instance. So the "scripting environment" here is literally the shell itself! (And you can "script" Acme from outside it, too, by mounting its command-binaries from wherever it keeps them, into your process's /bin dir.)

deepakkarki超过 7 年前

Not a native english speaker here, could someone explain what exactly "reified" means in this context? I tried searching online but it only led to further my confusion!

评论 #15623872 未加载

评论 #15624047 未加载

partycoder超过 7 年前

GUIs might be easy to use (e.g: IIS manager), but when you have to manage 50 machines, programability is important and automation becomes more important.

评论 #15620596 未加载

评论 #15620866 未加载

panic超过 7 年前

The drawing tool Ronin is an interesting experiment in mixed-mode command/direct interaction: <a href="https://www.youtube.com/watch?v=gifzjhyBwOc" rel="nofollow">https://www.youtube.com/watch?v=gifzjhyBwOc</a>

kadenshep超过 7 年前

I think what a lot of GUI's fail to do is to just get out of the way when it's failing to accomplish whatever task is at hand. You don't have the problem with CLI's most of the time because you probably have to implicitly compose commands to achieve the same thing the GUI might do in a single click.A button might kick off a set of tasks and aggregate the output into a final success message. If it doesn't work there's almost no way to dig into what's going on or even attempt to get the program to an acceptable state with whatever data you're working with.A CLI might have an analogous command that also kicks off a set of tasks but if it breaks/doesn't work and assuming the CLI is following a unixy model, you can run through specific commands diagnosing the issue or at the very least get to an acceptable state in your workflow that leaves you with a few options to work with.Any GUI, in my opinion, should just be a visual abstraction from a set of executable tasks that can be run individually. Take something like Github's Desktop client. In yester-years, when it first came out, it was pretty bad at handling git rebasing operations. But because of the way git was built and used most of the time, the Desktop client actually just called into the gitlib API or even just straight up wrapped git commands. If something broke, just like rebasing, I could actually take to the command line, inspect the state of the repository, and continue with rebasing via the vanilla git commands. And even then, when a git command doesn't act right, it might actually just be a wrapper around other more internal commands that you can execute yourself (i.e., git pull is actually analogous to git fetch; git merge origin/*). Compare this to a TFS error I've been getting for a few months on a legacy repository, with little to no information across application and system logs, and almost no information via google: "Provided parameter is not valid." Neat.I wish the described "composable application" if you will was just a standard across every application. Even in web applications I build I make sure there are "steps" in data processing instead of just monolithic operations. I take care to make sure steps can be kicked off individually with sane output. It seems like we lost this philosophy along the way across every level of application development and the linux ecosystem hasn't been immune from this in my experience. Windows has never really stepped foot in those waters until recently with PS. But most of the time, in my experience, we get GUI's with no recourse. If it breaks you just might be out of luck until a patch comes in or you can interact with the data yourself.Maybe one day if a program (even a web app!) doesn't provide a set of clean commands to run we'd look at it like we do a badly designed GUI, with disdain and disgust.

moocowtruck超过 7 年前

i guess we should start making them "clean" and start removing all those useful flags

feelin_googley超过 7 年前

A debate that never grows old?Against better judgment, I will bite.The author makes a valid point. Consider command line history, and command line editing via vi or emacs bindings. I use sh like a REPL all day, every day. I make constant use of searching prior tasks with Ctrl-[ + / or fc -l. I also have hundreds of short, saved scripts.I do not use a mouse or X11, no vim. I do not use a "clipboard", other than tmux buffers. Everything happens through editors/pagers like sed, vi and less. There is constant iteration. What is the GUI equivalent? Keyboard macros?The ultimate aim is to make tasks non-interactive. To script away the interactive work. Automation. This is in direct opposition to the philosophy of the GUI: that work must be interactive, and to make interaction more pleasant.But there are so many differences and similarities between CLI and GUI. What really separates them and makes me choose one over the other? If I can pick just one point of differentiation: Most times, CLI is more reliable. What does reliable mean here? It means robust. Less likely to fail.Assume that for comparison we can have both GUI and CLI versions of the same applications. And that the GUI is more than just a "skin" over the CLI.Show me a GUI application that is more reliable than the CLI version. I will take notice.But to get me to switch away from CLI usage, one must show me many GUI applications, all more reliable than their CLI versions.An entire system of fast, robust GUI applications, all more reliable than CLI alternatives.This might be possible. But it is not available as of today AFAIK. And I have to go with what works. Today.FWIW, I am an end user not a developer.

评论 #15620671 未加载

评论 #15621454 未加载

nnfy超过 7 年前

Graphical interfaces are useful to me personally because unlike a CLI, there is substantially less in the way of functionality that I have to remember, especially for programs which I rarely use. It is painful to input -h args and read through pages and pages of options to find a handful of the options that I need, especially when I am using something new.I've given light thought to the possibility of writing some kind of hybrid which acts as a general purpose terminal, but can somehow provide more information in a graphical manner-even something like directory traversal would be drastically simpler, IMO. Of course, this is not a trivial problem.Are there any existing shells which hybridize GUI and CLI?

评论 #15621386 未加载

评论 #15622312 未加载

评论 #15621039 未加载

kilon超过 7 年前

CLI is nothing more than a form of GUI. Hence GUI is fundamentally superior and the only ones willing to live in the Stone Age of CLI are some coders. What is more ironic is people who think that any CLI can come remotely close to the power , flexibility and extensibility of GUI. There is literally nothing that the GUI is not great at,it’s just that most coders have no idea how to design a GUI and that is reflected in the terrible state of GUI APIs and coding in general. I have been coding 30 years now , started from CLI and as soon I could converted to GUIs and never looked back.