"Expression" as the author defines it seems to be very narrow. Users of Photoshop or InDesign or Illustrator or Maya or Logic or Premiere Pro most definitly do express themselves, even though they are operating a GUI. GUIs are widely used for expression. Does the author want to suggest that CLIs would better serve the needs of all who want to express themselves?
Users of Photoshop or InDesign or Illustrator or Maya or Logic or Premiere Pro most definitly do express themselves
But in those programmes, the GUI is more like a keyboard of a CLI than the actual programme. The GUI controls are used as tools to use on the main area, the drawing area. A graphical programme like photoshop presents you with a massive empty whitespace for you to draw in. It doesn't tell you where to draw, or what colour to draw. It allows you choose any colour you want. Once you paint some red, you can then paint any other colour.
In this way the programmes you list confirm the "unbounded, "lack of constrains" and "newbie unfriendlyness" of the CLI.
A newbie doesn't know what commands to type into bash, and they don't know what colours to put down first in photoshop.
No, I think the analogy is apt. I think you're looking too shallowly and only looking at GUI/CLI, and thinking that Photoshop, being a GUI, fits into that world. Whereas Photoshop has more in common with CLI tools than many GUI programmes.
Have you ever seen a professional autocad user? How would you define that? A blurred line between the terms CLI and GUI is not a True Scottsman. It's an observable reality.
Long ago I used Autocad regularly for work. When someone gets really productive with it they tend to use one hand on the keyboard for selecting menu items and typing short CLI commands and the other for picking points and dragging selection boxes.
That kind of interface really does attempt to combine the best of both worlds, but at the expense of a big learning curve.
I’m quite confused. Everyone seems to disagree with me by vehemently agreeing with me. As you yourself say: Expression is not reserved for CLIs. GUIs can allow for it, too.
I’m not trying to bring down CLIs here. What I don’t like, though, is how the author of the article tries to bring down GUIs to prop up CLIs. That’s just not necessary. GUIs are used by so many people to express themselves and it’s patently absurd to claim otherwise.
Basically I am disagreeing with the validity of the discussion in general. There aren't agreed upon meanings for either term, so there isn't much point in going forward.
Cars vs. musical instruments to GUIs vs CLIs is an analogy, it won't work in all scenarios, but I think it's a pretty good analogy for explaining how CLIs work for people that have never used them or think they are antiquated.
In the case of Maya (and his cousins like Houdini, [ex]Shake...) every gui action is a word in an embedded DSL/bindings api (mel script, hscript, python). Maybe Adobe products too, but the javascript parts aren't a cultural feature of the application. Maya is as macro-capable as Emacs, you operate buttons, open the console log, copy the last instructions and drag it into a toolbar to have a new operation.
Plus the underlying reactive dataflow model is like a limited mathematical language. The gap between GUI and CLI is short here. So even without relying on text, you still can build operators (Houdini does this to a great extent, even the skeletal system is build out of user-level geometric primitives)
Some software that took the growable GUI a step forward is Luxologic Modo, here GUI tools are combinators that you sequence in a `toolpipe` to suit your needs, kinda like building a function out of lower level ones.
To finish on a blurry note : text doesn't exist, bytes lead to intepretation/action aka a function of the application model, I see no real reason that visual interactions can't be made 'linguistic'
You are talking about possibility. I have no doubt that it’s possible to manipulate images, sound and videos with CLIs. The question is whether that would be the optimal way.
When I worked with Photoshop, after a while most of the time was spent in a shitty point and click batch instructions editor, it should have been a text file in Vim.
You are taking the "expression" too far. We are talking about expression at the time of doing, not at the by-product of doing. GUI constrains you, it limits your expressive ability to tell the computer what to do. CLI is extremely expressive, it allows you to tell the computer what to do in very elaborate way, not only by having more options available for each command, but also by allowing you to combine things in ways GUIs simply can't allow for.
We are not talking about end products of this communication between computer and person, its output which could be images or software you created with the computer and which also allow you to express yourself in the more broader sense.
I'm not the grandparent, but I use TikZ to "programmatically" create graphics in LaTeX. It is much faster and looks much better than what I produce in the GIMP. (See e.g. http://www.texample.net/tikz/examples/.)
Of course, I'm drawing graphs and geometric objects, not trying to do "photo work" - but CLIs can be an excellent interface to some kinds of graphics.
No, I'm not. If you read carefully you will note that I'm talking about your expressive ability to tell the computer what you want it to do. Not about your ability to express yourself through a medium like video or images.
By the way, there are some great CLI tools (like ImageMagic) to manipulate images from the CLI and these are indispensable for batch editing large collection of images and other applications (image analysis), but I was not referring to that.
Ok so I want to select the pretty green color from a photo for future use. In MS paint it would be two actions select the color selection tool and select the color. How do you do that from the CLI in more expressive way?
Why should you be able to "select the pretty green color from a photo" via the CLI?
That's my point - just because it's the wrong tool for some hyperspecific job doesn't imply anything useful in general.
But if you really want to pursue the analogy, we could in fact come up with a command line that selects the green color value from a certain area of an image a lot easier than one could edit a non-image file using MS Paint (though I've seen that done too).
I think GUIs and CLIs can both be "valuable tools for expression".
But Photoshop is an example of something that's particularly good for the GUI. It's not representative of most things that people do when they're interacting with a computer.
The main thrust of the article is that CLIs are expressive, and GUIs are not. I came up with a counter example QED.
He pushes this topic by talking about Unboundedness vs Boundedness and Internalization vs externalization. What he seems to fail to realize is that internalization and unboundness are not properties inherent to CLIs nor is externalization and Boundedness inherent to GUIs. Those properties are a function of how you designed your application and user interaction not the medium by which it is accomplished.
The discussion is getting nowhere because the author is not even wrong. He's conflating too many things and picking analogies that sound correct but don't make any sense once you dig deeper.
A lot of the things _I_ do in Photoshop could probably be done more efficiently in a CLI (read DSL) than a GUI (and enable me to create and manage reusable components in a better way - some kind of mixins for example).
Now, a lot of what I do is adding (and tweaking!) effects and filters bound to shapes, selections (most often based on shapes) and layers, it would be harder to create an efficient CLI to _draw_ arbitrary shapes, but I don't used Photshop for that anyway.
Alright then. Is it possible to be somewhat systematic about this?
Things that humans create with software:
– Text
– Images
– Sound
– Video
– Algorithms†
All those elements can be glued together in different ways. Images and text, for example, can be glued together to create a magazine or newspaper layout. Text, images, sound, video and algorithms can be glued together to create a video game. Separate software for gluing stuff together is quite common. (You don’t really write and edit texts or edit images with InDesign but you bring texts and images together.)
Maybe I’m wrong about this but it doesn’t seem to me as though GUIs are the exception or a special case. They seem to be quite common.
—
† I’m not sure about this one. I think it deserves an extra category even though most people use text to create them. It seems wrong to me to put novels and algorithms in one category, it would be a disservice to both.
There are different ways of looking at this. In some way video and images are one and the same – you get video from glueing images together. It seems, however different enough to deserve its own category. Algorithms seem similar to me.
>It'd probably be useful to pick some other examples to discuss.
Maybe you can help with this, the author certainly didn't.
Let me try:
Firefox vs. Lynx
IDE vs. makefiles/make/compile
Word. vs Latex
Excel vs. ????
Outlook/Gmail vs. Pine?
Does one of those encourage expression over operation? Probably the closest is Latex, but still I don't see how it would be more expressive than what someone who spends equal time learning Word would accomplish with Word.
Because Lynx (except for its dump mode) and Pine address characters on the screen in two dimensions, I consider them to be graphical programs. They are just very limited graphics. There is a difference between a program which displays text on the screen and a program which prints its output to stdout.
Are we really having the GUI vs CLI holy war on HN? Here's how to deal with this question.
1) Design a nice DSL to express whatever it is you want your users to be able to command.
2) When you build the GUI, have all the gestures correspond to a particular DSL expression.
3) Add a shell where the user can type arbitrary expressions in your DSL (and for that matter, load files with DSL commands and execute them).
You're done. People who want a GUI have one, people who want a CLI have one, and there's a nice clean upgrade path from the GUI to the CLI. In fact, that's where this approach really shines: when a GUI user decides he needs to automate something, you can give him a single clear expression to type for each gesture he's used to making, and at first he'll probably just memorize those and use your product in exactly the same way with the CLI as with the GUI. Once he gets used to the CLI itself, he'll probably start tweaking the basic expressions you gave him and eventually feel comfortable enough to write his own. It's a nice security blanket for people who are basically learning to program to have a set of magic spells they're confident they can use no matter what.
This is basically exactly what Emacs does--every single GUI action, be it a keyboard shortcut, a menu item, a mouse click or even a touch gesture[1] maps directly and very unsubtly to an elisp function. This means you can go from just using Emacs like a normal text editor do doing really complicated things with elisp in a relatively straightforward way.
Coincidentally, I don't see how Emacs is a CLI program, even if it does have a text-only mode: the text-only mode just draws the GUI elements with text the way other programs draw them with pixels. Of course, it's a tool heavily optimized for power users, but that's a different story.
But the argument here seems to be that forcing users to use the CLI will make them use the more powerful features that they won't otherwise use with a GUI that's good enough for them. Or something like that. The useless analogies in the article don't help.
That's my point - in my book this is a solved problem. The GUI vs CLI thing tends to be a religious argument, which (in computing) always means that you actually want both.
I agree the original article is pretty nonsensical, I was just trying to prevent my having to read an overly familiar argument again.
Not to overstretch the metaphor, but it's not that black and white. Something as simple-seeming as manual shifting on your car can change your experience of driving completely, making you much more aware and attentive of what's really going on between your ass and the road. It makes you a real part of the vehicle's decision making process. (The description I like is "It's like having a conversation with your car.")
And that from what seems like a trivial change, just a single extra degree of freedom; one that most find just an annoyance. To bring it back around, it's possible to bridge the gap, providing a powerful and easy-to-use interface. But it will probably mean a lot of your users asking rightly, "But couldn't you just do that for me?"
The appropriate answer is something like, "Yeah. I could also just go to the store and get your groceries for you, and you'd never have to leave the house. Do you want to be cargo, or do you want to drive?"
If you're missing this aspect, musical instruments (to take one example that I sometimes wonder about) can easily seem designed to be "hard" to use. Compare a computer keyboard, with its clear labels, to the (to a newcomer) totally opaque grouping of the keys on a piano.
Now, I still think the keys could be labelled without any threat to the possibilities of expressing one's creativity, but it's a bit less annoying, having read this. :)
I think part of the resistance you'd meet to labeling piano keys is that you're highly unlikely to be able to play well if you depend on looking at the keys, as it slows you down too much to be able to play anything but the slowest pieces, whereas you can write well (though arguably not type well) on a keyboard while still looking at the keys.
As a teaching tool, labeling can work for both, but as a crutch for people who are less than proficient, labeling does not work well for someone trying to play the piano. There's a greater need for getting to a certain level of proficiency if you wish to play the piano than if you wish to use a keyboard.
"Physical interfaces (and by extension, GUIs) cannot combine at will to create new behavior."
Or should it say that we don't yet have good enough GUIs that allow combination at will, to create new behavior? I don't think it is correct to say that this is impossible.
It's difficult to image what this would mean for GUIs, but maybe we could get some ideas from the DSL stuff for example Microsoft and JetBrain were doing some years ago.
What it says is just completely untrue.. there are examples in this thread, such as Maya.. any form builder is based on combining components on a screen.. these same types of forms are coded by hand by web developers (like myself), yet contain no additional functionality. Components can also be combined, linked and configured with GUIs oftentimes more efficiently than integrating libraries. Colored ASCII code and command lines are great and I use VIM and bash constantly these days, but its just ignorant and irrational to try to say that is the best way to express yourself on a computer.
What I think is going on is that people are rationalizing the way they work and also, and this is the main thing, rationalizing a general feeling and stigma for programmers associated with A) using a graphical interface and B) doing anything that isn't inside a terminal and/or classical text editor window. "Real" programmers use bash and emacs/vim/TextMate or whatever. If you're not editing textual source code, you must not be programming. If you're not programming, you're not a real programmer.
I think this is the primary idiocy holding back not only software development but also quite a lot of potential business productivity gains from custom software.
What is programming? Is it wiring up vacuum tubes? Punching cards? Entering assembly code? Manipulating pointers? Generating Rails apps automatically from the command line? I think that programming shouldn't be limited to ASCII text. People who think that should educate themselves about things like knowledge representation and reasoning, components, program generation, dataflow, structured editing, intentional programming, anything Jonathan Edwards put out, etc.
TLDR: you're a bunch of retards. BTW contact lenses were invented in 1887 and MacBooks are completely overpriced.
TLDR2: the number 1 and number 2 things holding back software development are source code and CLI.
Do you mean that once a GUI is combinable, it will be as hard to understand as CLI? That makes sense to me; infinite potential combinations will always be harder to understand than a limited set of actions.
I don't think he thought it all the way through, but I do think the author is onto something. A very important aspect of any kind of interface is to what extent it lets you combine and compose actions. But a) the line is not the same as the GUI/CLI line and b) it's a matter of degree.
A CLI could easily just be a set of five commands with no options that are roughly orthogonal. There is not much potential for constructing powerful, expressive commands, nor much of a learning curve. Just memorize the list. On the other hand, you probably don't need to look far in this thread to find an example of a GUI that allows powerful combinations of commands/effects/etc.
Depending in the design of the interface, there can be different degrees of combinability. I think the main point of the article should be (if it isn't) that what degree you want depends on the domain the interface is for, whether it should allow an infinite variety of actions.
Apparently this got lost in his stereotypes. By CLI he meant roughly Unix, and by GUI he meant a point-and-click GUI. There are many more possibilities in between.
Maybe there isn't much progression after you learn how to drive a car for normal people. :) Perhaps similar to lack of progression after learning how to email or browse the web for most users. Sure, you can only move the wheels, pedals and gear selector in certain ways. Isn't this equally true of the mouse, keyboard and guitar? And how is a steering wheel visually suggestive to those unfamiliar? Or the pedals? Sure, you can't pipe your car without making physical changes. But hacking a fuel-cut-defender is still hacking. I guess I just dislike using a car, guitar and EMACS as an analogy. Other than hardware vs software, they are very similar to me. I'm familiar with all three, and the one I'm least likely to modify is my guitar.
CLIs can benefit from autosuggest, a lot. I don't want to type too much or risk making typos. So they should suggest the legal choices, and order them by most common first (or maybe alphabetically). For those who don't like the autosuggest popping up automatically, you'd have a setting to establish a key combo to bring it up. Also, it's nice to underline possible spelling mistakes, and be able to hyperlink words to lists of related locations when I click on them.
Meanwhile, GUIs can include a "drop into CLI mode".
If we have a GUI that has a CLI mode with autosuggest, I would think this is the best of both worlds. Often times, I just want to design a COMPONENT, and then go right back to using the GUI.
Great textual interfaces also try their best to externalize knowledge. That's part of the reason behind DSL's , Object-oriented-languages and good API design.
And because they're better at this, they're more useful than GUI's in many cases.
I don't know where to start. Sure, training people in Latex will eventually make them churn out better looking documents than Word, but the initial training costs and learning curve are going to be really high for the average office worker for who Word with the ribbon is overkill.
I am all for being against conventional wisdom, but surely someone would have done some experiments on these lines to unlock the creative expression of their employees? There are even a bunch of companies who allow and provide facilities for napping since they believe it helps be more productive. What's stopping them from switching to CLIs exclusively?
Also, he ignores the power of macros(VBScript is very powerful) and keyboard shortcuts in GUIs. Watch an occasional user of Office vs. a pro user and you can see the difference clearly. How many here can profess to know about every feature or shortcut in Word or Excel? Just see http://www.shortcutmania.com/Microsoft-Word-2007-Keyboard-Sh...
Same with IDEs, you can automate a lot of tasks if so choose to spend your time on it and rarely even use the mouse. You only hit a wall in the most simplest of applications(same as CLI), for complicated applications, there's a ton of room to explore.
It makes more sense to rant against programs/devices(browsers, pdf readers, watching movies) that encourage consumption versus the programs/devices that encourage creation(photoshop, IDEs, writing HTML in notepad). That's the only way the analogy of driving a car vs. playing a guitar makes any sense.
I can't fathom why the author is trying to turn that argument into a CLI vs. GUI argument that superficially sounds plausible but just falls apart with a little scrutiny.
When you start scripting with macros or automation tools, you've just left the limits the GUI imposes for a CLI environment, with all that entails. That's not a disagreement, that conceding the point.
Nothing stops a "GUI app" from having a CLI or vice versa, though I observe that generally an app can be fairly cleanly identified as considering one or the other the "primary" interface, with the other a clear afterthought/second priority.
> you've just left the limits the GUI imposes for a CLI environment
Not all macro and automation systems are text-based. Automator and Photoshop actions both let you create user-defined behavior by combining primitives while still taking advantage of the discoverability and spatial layout of a GUI.
In other words, GUI apps can and do incorporate CLI elements. But CLI apps cannot incorporate GUI elements like click-to-select. So would it be accurate to say CLI apps are more limited than GUI apps? Or is the point in the article about forcing people to use CLIs so that they have to know about the more powerful features(or give up trying to use the program)?
Or does he mean it's a good thing to replace the car's interface with a bunch of strings like a guitar that allow you to steer, brake and accelerate and change gears and this will allow for more creative driving? As I said, the article is not even wrong.
Too strong. You've defined "GUI" as something that can include CLI elements, but then turned around and defined CLI as being unable to include GUI elements, so you end up in a tautological circle.
A "CLI app with a GUI" is something like emacs in X11 or gvim, where the GUI is clearly a second-class citizen/afterthought, but it is there. Alternatively, you can look at something like the various Linux apps for ripping DVDs, which are mostly nothing but GUI shells around various transcode and mplayer commands, and it shows. To the point that I once bashed one of them into doing what I wanted it to do, rather than what it wanted to do, by exploiting a command-line injection in the so-called "GUI" to inject a command-line parameter that superseded one of the earlier ones the program jammed in without asking me. (Subsequently I scripted up a simple rip that meets my usual use case, but the GUIs are nice when I want to save subtitles or something and it's harder than just one mencoder call.) Considered as a system, these are GUIs around underlying CLI apps that do the real work.
A GUI interface can include CLI elements because it is technically capable of showing a CLI interface.
If a CLI interface can include a GUI, can you use it over in a SSH terminal? Or on a Linux box without X(or the equivalent) and all it's bloat being installed? Or on Windows 2008 Server Core? You're pretty much redefining CLI at this point and cutting away some of it's advantages too, like being able to run on very low power devices like routers etc.
"If a CLI interface can include a GUI, can you use it over in a SSH terminal?"
Yes, you can use every bit of functionality in all the software I cited over SSH, you just don't get the GUI. (Excepting anything purely GUI-specific, like opening a new window in emacs, but that's a small set of targeted commands.) That's why I cited those examples as CLI apps with GUI overlays. I could cite some others, too, like fetchmailconf, a GUI for fetchmail that is optionally used for configuration of an otherwise fundamentally CLI app. Unix is full of these things.
People that need training simply to do their job are operators, not creators. They don't need a CLI, nor should they use one. As the article states:
There is a time for operation, and a time for expression.
Most interface debates are misinformed because they are
about creators complaining about operation interfaces, or
operators complaining about creation interfaces. We need
both. But we also need to understand when.
It depends on the use-case. A majority of Photoshop users probably only use it for occasional and singular tasks, like resizing an image for sending it via email, or retouching a good photo with bad exposure.
On the other hand some users have a need to do batch processing and in that regard Photoshop is surely limited. Also, Photoshop is so god-damn effective in 80% of the tasks that most users never learn the mechanics of useful effects like smart-sharpening (just an example), which is really bad because the same techniques for doing a manual smart-sharpening can be used for lots other effects.
Do note that Photoshop does have scripting support, but I don't know if it is an afterthought or not (and this does matter).
Are Visual Studio users just operators of an IDE?
Many of them are operators and it's freaking painful to watch.
We already have Latex to substitute for Word
Well, actually Microsoft has yet to create a replacement for Latex. The layout of a Word document gets broken a lot depending on the fonts installed, on the Word version you have or even because of the printer drivers you're using. I even saw the same document rendered differently on the same machine, changed from one application instance to another. Granted it was a badly formated document, but that's just sad.
Latex is still the only general-purpose solution for producing high-quality documentation that is consistently rendered well across devices and that can be properly translated into PDF or whatever format you want without splitting hairs. It's also much more productive for expressing mathematical formulas.
Lynx to substitute for Firefox
This comparison is not fair because HTML itself was meant to be rendered, not read directly.
However, I still don't see professional designers / developers using WYSIWYG tools for writing HTML, like say, Dreamweaver. They may draw the layout in Photoshop, but writing HTML? That's done by hand, unless you're speaking about incompetents. That may change but after more than 20 years after the web was invented, the fact that no WYSIWYG editor is capable of being good enough for the task truly speaks volumes.
Oh please. Don’t compare Latex to Word, compare it to InDesign. Word is word processor with some typesetting functionality crammed into it, certainly not the ideal tool for creating beautifully typeset documents.
Latex is awesome if you stick to the (very sensible) defaults. It basically creates beautifully typeset documents for people who have no idea about typesetting. (That’s a good thing, by the way.) It’s not all that great if you want to go very far beyond that and in that respect InDesign runs circles around it.
I agree. I find Latex very limiting, in the sense that anything that falls outside of its (admittedly extensive) library of functionality is nigh impossible to do. Latex has a system of "environments" and a box model that satisfies the basic use case of spitting out a nicely typeset article, but it's not the tool I would turn to if I wanted to precisely justify a paragraph underneath an image (the above comment is correct: look to InDesign or something similar).
Latex (or more specifically, TeX) was groundbreaking for its kerning and typeface support. It still has the most extensive system for unambiguously typesetting complex mathematical equations. It appeals to a certain kind of person who wants to have a canonical source in plaintext controlling layout. But you're kidding yourself to say that it is the most flexible and powerful tool for typesetting on the market today.
>> Are Visual Studio users just operators of an IDE?
>Many of them are operators and it's freaking painful to watch.
And many of them create awesome games, OSes, applications and websites that hundreds of millions of people find useful and enjoy. Funny how an open-ended tool works, isn't it?
>Well, actually Microsoft has yet to create a replacement for Latex.
They have EPS.
>This comparison is not fair because HTML itself was meant to be rendered in a graphical interface.
So you mean GUI is for consumers and CLI is for creators? But is Photoshop CLI or GUI? What about Eclipse?
Regarding Visual Studio operators, I don't think you and bad_user are talking about the same people. I suspect you would eventually find, if you talked it over more, that the people he labels as "operators" are not the ones creating the awesome games, OS's, and other software.
CLI is for noobs, Lisp macros and PERL programs are way more powerful than CLI.and can be exactly customized to your particular task that you're trying to accomplish rather than artificially limit you to a list of non-extensible options like CLIs tend to do.
Great example. Before Twitter, Google had already begun the re-education of the masses to use text-oriented interfaces with things like "label:" in Gmail search and "filetype:" in Google search.
