Slashdot Mirror


The Case Against GUIs, Revisited

snydeq writes "Deep End's Paul Venezia advocates the importance of the command line, in light of the increasing use of GUIs in today's technologies, as well as the increasing perception among admins that proponents of the CLI are dragging computing back to the 'dark ages of the C:\ prompt."

39 of 720 comments (clear)

  1. This, perhaps... by troff · · Score: 5, Insightful

    ... speaks more of the admins who assume that "CLI" == "C:\ prompt".
    Or the idiots who think "CLI" == "the GUI in front of me is therefore made unusable". The people at "GUI Industries" can't make a link or shortcut to the appropriate script?

    Why would you trust an admin who can't, as TFA indicates, edit a text file?

    1. Re:This, perhaps... by NFN_NLN · · Score: 3, Insightful

      GUI = makes it easy to do one off tasks, because the interface can be made intuitive.
      CLI = makes it easy to do repetitive tasks, because they can be easily scripted.

      Even repetitive image manipulation is best achieved with scripted command line tools. Don't believe for a second someone had inserts watermarks into photos!

    2. Re:This, perhaps... by msobkow · · Score: 3, Insightful

      I rely heavily on scripting for one reason: scripts can be captured in version management repositories. GUI interactions can't.

      Aside from that, my database creation scripts are huge. I'd hate to have to open each script in a GUI tool to run it instead of being able to run them all as a batch (as intended) through a bash script (which in turn invokes the compent bash scripts that actually invoke the database CLI.)

      --
      I do not fail; I succeed at finding out what does not work.
    3. Re:This, perhaps... by 19thNervousBreakdown · · Score: 5, Insightful

      Why would you trust an admin who can't, as TFA indicates, edit a text file?

      Or write a safe regex:

      $ echo '123a123b123c123' | sed 's/123.123.123./321.321.321./g'
      321.321.321.123

      Gotta love the way he hand-waved the "half hour on a Wednesday" to do the whole transition, too. As someone who's done it, it is never, ever, ever that simple. Have fun finding bugs like the above, fixing them, finding out that your fix invalidates your entire solution, approaching it from a different angle, looking up an obscure syntax you can't remember even though you use sed/awk/grep every day, finding out you've got a slightly older version or yours wasn't compiled with --enable-double-buttgrep ... sure, the "30 minutes" sounds great when you're trying to make a point, but it also sounds ridiculous to anyone who's actually done it twice.

      I love me some CLI, and I'd lose my mind if I didn't have it available, but promoting either one to the exclusion of the other is asanine.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    4. Re:This, perhaps... by sarysa · · Score: 5, Insightful

      It seems that the one thing that bash-fu black belts and complete novices have in common is that they don't realize both can be used in parallel...

      --
      Charisma is the measure of someone's ability to lie with a straight face.
    5. Re:This, perhaps... by lennier · · Score: 4, Interesting

      The people at "GUI Industries" can't make a link or shortcut to the appropriate script?

      Yes.

      This is a huge flaw in almost all current GUI models. They've reinvented a whole object/component-based architecture on top of the old process/file-based CLI-accessible portions of the OS, and then provided basically no scriptability of those objects, and even less ways to interface the topmost GUI level to any scripts you do manage to somehow cobble together.

      (Possible noteworthy exception-in-progress being PowerShell 2, Apple Automator (except AppleScript is a horrible language because it tries to be fake-English), and maybe some parts of RiscOS and OS/2. )

      But this object/scripting gap is something I noticed way back in my teens, in the 80s, and couldn't bring myself to believe that the Top Minds in software architecture had missed this glaring oversight. But they had. Apparently everyone was going to either program in raw C++, or click icons, and nothing much in between. Basically there was no thought put into anything like a 'Unix shell' for Finder / Explorer and friends.

      I mean, 5 seconds thought suggests that someone should have come up with a quick visual tool for dragging icons into a box, drawing lines between them, and having that save and load from a text file describing connections between components. And then make that a fundamental part of the OS and build all OS and application GUIs using that. If you ever came across a GUI you wanted to build for an application that couldn't be expressed in that language, then mark it as a bug in the language and extend the language.

      Then we'd have had something approaching the power of Unix scripting for visual desktops, and we would have . But no. We went for a 'all GUIs will be sealed binaries written in low-level assembler or C++" approach. Then we deconstructed the GUI as web pages, and again, first chance we got, we ripped out Tim Berners-Lee's HTML editor component from all web browsers, enforced a hard split between "web server" and "web browser", and once again destroyed the ability for users to do their own interface design and to program their own workflow.

      It's like we have this obsession with making things hard for ourselves just to keep application developers in jobs.

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    6. Re:This, perhaps... by lennier · · Score: 4, Insightful

      GUI = makes it easy to do one off tasks, because the interface can be made intuitive.
      CLI = makes it easy to do repetitive tasks, because they can be easily scripted.

      That task split between GUI and CLI is exactly what I think went wrong when GUIs were first designed.

      What we should have done was created a GUI which has exact formal one-for-one-correspondence with the underlying CLI, so that for any given task, you can use the interface of your choice that works for you - or create new graphical interfaces for the special custom jobs you end up doing multiple times.

      And it wouldn't have been that hard to do. GUIs involve message passing, but we chose not to expose those messages as scriptable 'commands' at the same level as a CLI. We hid them and required C++ and other system/application languages to send those messages in full, then exposed a tiny fraction of them to various "scripting languages". But you can't write all applications in scripting languages, so it's a lossy conversion filter.

      The result is, we've got at least three levels to our systems: a reasonably transparent 1960s-batch-system derived command/process/file based layer, an opaque 1980s Smalltalk-derived object/component layer, and finally combined applications/GUI/preference files launched by the 1960s layer which orchestrate the 1980s layer to do stuff. We can't use the 1960s layer (CLI) to do everything the 1980s layer (GUI plus services/components/DLLs) can do, because the 1960s layer has fundamental connection concepts like piping and "everything is a file which is an I/O stream" which simply don't exist in the 1980s "everything is an object" layer. It's impedance mismatch at the OS level.

      The big problem with an impedance mismatch is that you can't solve it by adding more lossy-conversion layers. It can only be really "solved" by creating a new abstraction which has the features of both, but that seems impossible now that we have a huge weight of legacy code. I'd been hoping that Linux in the 2000s would give us some hope of breaking away from the Windows cruft and coming up with a simple unified desktop framework. But GNOME and KDE seem to have just fragmented the situation even more.

      Wish I could see a plausible way out of this mess.

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    7. Re:This, perhaps... by Anonymous Coward · · Score: 3, Insightful

      That task split between GUI and CLI is exactly what I think went wrong when GUIs were first designed.

      What we should have done was created a GUI which has exact formal one-for-one-correspondence with the underlying CLI, [...]

      And that GUI would be unusable for most of the time. Making a good GUI is not about just slapping together a number of widgets, it is about usability. For example, take curl. It has 139 or something options. A GUI would have to present all of them and if the GUI is to be usable it shouldn't be too hard getting to any of them, that is, it should not be hidden away somewhere deep down. Either you get a very cluttered GUI with every option visible or a GUI that is more suited for a certain task but that is not as good with general tasks.

      I think that the split is exactly what is needed to make the right tool at the right time. There is no silver bullet. For some tasks GUI is superior, for other CLI rules.

      As an analogy, think of communication. Sometimes we prefer written (contracts for example). At other times we prefer verbal (talking to your therapist). You cannot say that there is ONE right way to communicate and all forms of communication should adhere to the same strict doctrine.

      Having said that, it should be obvious that having skill to use BOTH CLI and GUI gives you flexibility and power. The problem today is that too many people are afraid of using a CLI and try to find GUI versions, complaining when they aren't powerful enough. The problem is most likely because of the task they wish to do.

  2. Dead on by Hatta · · Score: 3, Insightful

    This is dead on. Human beings invented symbolic language because it's simply more expressive than pointing and grunting. CLIs are superior to GUIs for the same reason.

    --
    Give me Classic Slashdot or give me death!
    1. Re:Dead on by StikyPad · · Score: 4, Insightful

      Human beings invented symbolic language because it's simply more expressive than pointing and grunting. CLIs are superior to GUIs for the same reason.

      CLIs are superior to GUIs in the same way romance novels are superior to sex. Sometimes taking the time to carefully describe things in clear, unambiguous detail is important, but sometimes pointing and grunting is both more effective and and more satisfying.

      And when's the last time you edited photos, video, or audio with a CLI?

    2. Re:Dead on by tweak13 · · Score: 4, Informative

      And when's the last time you edited photos, video, or audio with a CLI?

      When I was a sysadmin at a radio station, I wrote scripts that processed audio, including cutting and splicing. Having it automated saved a hell of a lot of time for the people that used to have to sit in front of a GUI and do it.

      Of course, there's all kinds of audio work that couldn't be done by script. The point is, you need both kinds, even for audio and video.

  3. Talk to your computer? by MrEricSir · · Score: 5, Funny

    I'm afraid I can't let you do that, Dave.

    --
    There's no -1 for "I don't get it."
  4. I don't get it. by arcade · · Score: 3, Insightful

    I haven't used windows since '99.

    looking around my desktop right now, while posting to slashdot, I have chromium running, and 7 xterms. Two of'em are running irssi, the others are just nice little windows to do various bits of work in.

    I live and breathe in a CLI environment. I can't really remember doing much useful in GUI's except lookup information (for which it's suited perfectly well).

    But why on earth would you do configuration in a GUI? Why would you ever program in a GUI, instead of vim or emacs?

    I just don't get it.

    --
    "Rune Kristian Viken" - http://www.nwo.no - arca
    1. Re:I don't get it. by geekoid · · Score: 3, Insightful

      easy of use. I get far more from VS then either emacs or Vi provide. And yes I have used them extensively.

      A good GUI make configuration a snap. Should it be the only way? of course not.

      It's funny, people complain about GUI speed, but then never use the shortcuts. They say CLI is better, but then use all kinds of shortcuts.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    2. Re:I don't get it. by 19thNervousBreakdown · · Score: 3, Insightful

      But why on earth would you do configuration in a GUI? Why would you ever program in a GUI, instead of vim or emacs?

      Because it's way, way easier. Don't get me wrong, I love my VIM, I use sed at least weekly, I've built 5,000-line programs in awk (awk, not gawk, and god help me not by choice), but here's why I use a GUI to program (when it's available):

      • Autocompletion. Yeah, you can get it in whatever text editor, but it's not nearly as good. Ctags doesn't handle C++ well. In Visual Studio using C#, I can add a method, not even save, and there it is in my autocompletion list, auto-populated to the first signature, and as I add parameters it auto-selects the one that matches the number and types of parameters I've entered, with the short documentation right there.
      • Tabs. I sometimes have 30-40 source files open in a single project. Tabs Studio (not affiliated in any way, it just saved my sanity) lets me have all those files instantly visible, clickable, alphabetized, noted if changed, and the last viewed file highlighted. Are all those things possible in an ncurses app? Sure, with a 240x80 display, but it'd be cramped even then. Proportional fonts have their uses.
      • You can put a CLI inside your GUI. I have immediate sub-windows inside Visual Studio, I have a Cygwin window open at all times, with screen and a few utilities with their own dedicated screen windows inside it.
      • You know what, fuck it, I don't feel like typing all this stuff out, you don't feel like reading it. Essentially, my argument boils down to a UI that has control over individual pixels has more potential visual display resolution than one that can only render a limited number of glyphs in a fixed array of rows and columns, and that's the only inescapable difference between the two. Imagine 9 more bullet points here where I say the same thing over and over.

      Do I miss stuff from VIM when I'm working in Visual Studio? Sure. But if you know the tools equally, and I know VIM like I know the palm of my hand, Visual Studio is just plain faster. But, your entire premise is invalid--a GUI or CLI is not a binary choice for a subject as large as "programming". Individual activities are better suited to one or the other, and a savvy user will use the most effective tool for the task at hand. A GUI can host a CLI or simulate it entirely, a CLI can't do either, therefore GUIs are objectively better unless the resources required for the UI is a concern.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
  5. Re:First post by twollamalove · · Score: 4, Funny

    Yes, but to master same functionality using windows batch files it takes a lifetime of discipline

  6. CLI is no longer essential by blair1q · · Score: 4, Funny

    CLI is not essential. It's a holdover from a time when we thought words were a good way to express function. And then left the 'e' off "creat" for kicks.

    Everything can be done in a GUI. I don't see why not. We just haven't made that happen yet.

    1. Re:CLI is no longer essential by Hatta · · Score: 3, Funny

      Everything? I'd encourage you to write an OS using a point and click programming language.

      --
      Give me Classic Slashdot or give me death!
    2. Re:CLI is no longer essential by Sc4Freak · · Score: 4, Insightful

      Uh, using a GUI doesn't preclude you from editing text. Windows is developed and compiled in Visual Studio, which is a GUI-based IDE.

  7. Re:Nobody needs a GUI or CLI by ron_ivi · · Score: 3, Insightful

    Some UI may go this way eventually, but I imagine most written/typed communication is still incredibly valuable.

    I imagine it won't be long before we communicate with computers very much the same way we do with people.

    For casual simple tasks, that means mostly voice (which computers suck at today) and a bit of gestures (which computers are OK at with a mouse).

    For anything complex, though, communication between humans is typically written - and I expect it'll continue to be so for computers for as long as people interact with them -- not because it's great for the computer, but because it's the best humans come to a high-bandwidth precise recordable communication channel.

  8. Re:Nobody needs a GUI or CLI by suso · · Score: 3, Interesting

    The frustration of doing this was foreseen by some of the writers of Star Trek. If you watch some TNG episodes where Geordi interacts with the computer, you'll see him getting frustrated with it not understanding what he wants. I always felt that Geordi was a lot like an IT engineer of today.

    We may be able to talk to computers, but I imagine it will be very hard to get them to the point that they understand each of our individual expectations. Even once we think they are comprehending, they still won't.

  9. Dark ages of the C:\ prompt by Sir+Realist · · Score: 5, Insightful

    Anyone who thinks that a command line prompt starts with a 'C:\' has no idea what they're talking about.

  10. CLI != DOS by tnk1 · · Score: 4, Insightful

    While the C:\ prompt would really be the Dark Ages all over again, command lines done right can be significantly faster to use for experienced admins. Not to mention they can also be used in diverse interface environments like serial connections in almost exactly the same way that they are used anywhere else. It's significantly easier to script from the command line as well.

    Just about every shell available on a UNIX-like OS is at least ten times better than DOS ever was. Lumping in bash with DOS is like taking a BMW and saying it is equivalent to a Yugo because they both have four wheels and an internal combustion engine.

    There's certainly a place for a GUI, and well designed GUI apps are lifesavers in big environments where seeing a graphical representation of 1000 servers as icons and being able to click and drag to select and execute group commands is a much easier way to work with that many servers. Having 1000 lines of text zoom by is going to be hard to take in at a glance. I love the GUIs that I use for certain tasks like visualization and management of complex environments.

    Still, anyone who considers the command line to be the Dark Ages either doesn't know how to type, doesn't understand how to use a CLI, or is simply trying to sell you a pretty GUI app.

  11. The Memory Connection by macraig · · Score: 3, Insightful

    Command lines discriminate against those with poor memories. GUIs make it possible for people who can't remember detailed shit to be productive without having to constantly refer to some other resource(s).

    I learned English well enough that I rarely require a dictionary, but I was never so lucky with programming languages and other syntaxes. I love my GUI... when it's implemented correctly. Paul Simon wanted his Kodachrome, and I want my GUI.

  12. Why not both? by Kenshin · · Score: 5, Insightful

    Why does this always have to degenerate into a Campbell's Chunky Soup "Fork or Spoon" debate? Why not just use the most appropriate interface for the task at hand?

    A GUI can be shit for some things, and (unless you live and breathe CLI) a CLI can be too complex and unwieldy for other things.

    --

    Does it make you happy you're so strange?

  13. Re:First post by kikito · · Score: 4, Funny

    And masochism

  14. Re:Raises hand by SpiralSpirit · · Score: 4, Insightful

    or you could have made a photoshop action while applying the first one, then told it to do the action to every image in the folder. done in less than five minutes. probably only about 1, if you know what you're doing. There's a lot to be said for knowing how to use the tools!

  15. Re:First post by Jeremiah+Cornelius · · Score: 5, Funny

    I like my CLI smartphone. With wget and Perl5, I don't need any of those useless, cluttery widgets for connecting GPS to reviews of local restaurants - and dialling is a breeze, as I grep through the flatfile of contacts I have acumulated by rsyncing from my desktop dump of the company LDAP.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  16. Re:First post by sortius_nod · · Score: 4, Interesting

    Batch files are easy. The only people I've found to have trouble with any sort of scripting are people who grew up only using GUIs.

    That being said, I grew up on old Macs and only started using windows at 15 when I got my first job in a computer shop. Not having used a CLI previously I dove straight into it and learnt all I could.

    The problem with the whole user/CLI disconnection is that there is a perception among certification/uni degree holders that once you finish your qualification you don't need to learn anything further. I saw this happen to many people who graduated with my fiance, they learnt Windows, learnt how to use the GUIs for admin, and nothing more.

    To be honest, I blame complacency and the fear of intellectualism for the decline in the CLI. It seems to be "cool" to be stupid in developed nations, intellectualism and learning are almost feared. Maybe it's due to editorials damming intellectualism, maybe it's to do with politicians damming intellectualism. I'm not quite sure, whatever the cause it's one of the worst things to happen to humanity.

  17. Re:First post by Anonymous Coward · · Score: 5, Funny

    At last, I've found another n900 user! Brilliant phone.

  18. pre-history vs. history by mangu · · Score: 3, Funny

    A dividing line in human history is the invention of writing. That's what differentiates pre-history from history. After the invention of writing we have records of what happens, before that it's up to archaeologists to dig ancient garbage dumps to infer things.

    Incredibly, there are people who want to run the inverse way in computing.

    What next, will we have to climb trees to use computers?

  19. Re:First post by Caerdwyn · · Score: 4, Insightful

    By your own admission you've devoted half a lifetime or more to developing computer skills. Should everybody have to do that? Are people who don't devote half a lifetime specifically to computing skills "stupid' and "fearful"?

    This is just a form of elitism. I'm not even going to call it intellectual elitism, as preferring CLIs is no more a demonstration of superiority or intellect than preferring GUIs is a demonstration of inferiority or stupidity.

    --
    Everybody gets what the majority deserves.
  20. Re:First post by im_thatoneguy · · Score: 4, Insightful

    The trouble with CLIs though is that the functions aren't always named whatever you would expect so you *have* to look up the function name and formatting.

    If a command line could be written as:

    "Take this image, resize it by 50% and increase the contrast 10%" then people would use CLIs all the time.

    Instead it goes:

    ImageProcessor ... /help ... ...
    ImageProcessor -scale 50p... /help ...
    Image Processor -scale 50p -filter (contrast,1.1) .. /help ...

    etc...
    You have to keep looking through a huge documentation system. GUIs at least present you with the documentation *AS* the interface.

    You don't need to know what the "Contrast" filter is exactly called, you just look through the list by default and choose the one that closest matches what you want.

    If we had smarter more adaptable CLIs people would be far more familiar instead you find out you missed a comma somewhere and it takes you 5 minutes to track that down. Or you try to figure out if adjusting contrast is even a function at all.

  21. Re:First post by msauve · · Score: 5, Insightful

    "By your own admission you've devoted half a lifetime or more to developing computer skills. Should everybody have to do that? Are people who don't devote half a lifetime specifically to computing skills "stupid' and "fearful"?"

    Yes, and yes, if their career is administering computers (or computer networks, which is what the article is about).

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
  22. Re:First post by lennier · · Score: 3, Funny

    Bah! You can learn to write every control structure with GOTO LABEL if you just twist your brain into a tortured nightmare of insanity.

    It's quite comfortable once you get used to it.

    --
    You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
  23. Re:Raises hand by lennier · · Score: 5, Insightful

    If a human is required, it's editing.

    That's your opinion. I think the point the original poster is making (certainly the point I'd make) is that our interfaces should be agnostic as to whether a human or a decision-making algorithm is driving them.

    Because otherwise, how are we going to take control of our workflow and delegate the automatable parts of it to automation, if the interfaces we use stubbornly insist that 'no, a human must be in the loop to do that!'

    This attitude, which sadly is rife among GUI designers, is keeping us stuck in the dark ages. It fundamentally shouldn't matter if a human or a program is doin any job on your desktop. End of story. It's not the interface's job to decide. If a script can take a look at a JPEG, apply a beauty algorithm and decide to fudge the colour contrast and recrop - and if a human can look at that afterwards and decide that it's good and keep it - well, then that's editing, isn't it? But it's done by a partnership of human and machine, as it should be.

    Don't force us to decide between human and machine for every job, and especially, as an application designer, don't impose your conception of what tasks should be done by which. As a user, closer to the coalface, I might well have a better idea. If your software gets in the way of my automation, it's wrong.

    --
    You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
  24. Re:First post by billcopc · · Score: 3, Funny

    Son, when I was your age, we didn't have GOTO. We had a stack pointer which had to be managed by hand, and WE LIKED IT.

    MOV AX,1202
    PUSH AX
    RETN

    --
    -Billco, Fnarg.com
  25. Re:First post by LordLimecat · · Score: 4, Insightful

    It is often worth doing cost-benefit analysis and determining if the time spent reading the documentation is worth the time that will be saved by using CLI.

    If someone asks me, for example, to add a user to active directory, it doesnt really make sense to research how to get LDIFDE or whatever to do an import properly. If, however, they hand me a CSV file of 100000 contacts and asks me to import them to active directory, then you better believe Im breaking out cygwin and awk documentation, and touching up on the active directory CLI tools. I may spend a few hours learning how to work them, but I will save hundreds of hours in time.

    This isnt a "heres the right answer" scenario. You have to use your brain and your experience to choose the right tool for your job. That, as much as anything else, is the mark of a good systems administrator, not knowing every CLI in existence. A knowledgable SysAdmin can be inefficient if he needlessly ignores some tools (GUI) that are perfectly suitable to a task just so that he can use the same tool for every task.

  26. Re:First post by rgbatduke · · Score: 3, Informative

    A nice example of the bash-fu mentioned earlier.

    To quote an ancient proverb -- "You can often learn to use a GUI in a day, and pay for that knowledge for the rest of your life."

    The Unix Way is to be able to chain together large numbers of short, relatively easy to use, powerful commands to create tasks that save days of work in a GUI, if any GUI exists that can facilitate doing them at all. Sure, it takes a while to learn, requires intelligence, is "expert friendly", but in the end you can work friggin' magic. That's why they call the masters of this "gurus" and call the masters of the Windows GUI "MCSEs".

    And yeah, even the best of the gurus use the man pages all of the time. Why waste neurons memorizing every single option to ls, or tar, or convert? It is enough to know the command name and that an option exists -- the computer itself is an extension of your brain that remembers every tiny option on request, if you choose to use it that way. And when you can't remember the name of the command, or aren't sure one exists, there is first "apropos", and then things like "yum list \*whatever\*" or google.

    GUIs are often stupid, nearly always broken somewhere, only do what the designer thought they should do (which often leaves out any sort of control at all over all sorts of functionality known only to those who understand what lies behind the curtain where the command line provides access), and are slow and inefficient for nearly all tasks except things like "drawing" or otherwise "manipulating graphics" or "playing games", largely because they force you to take your fingers off of the home keys to use them.

    rgb

    --
    Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.