10 ms·

GUIs Considered Harmful (1992)

93 points by earenndil 8y ago

meta_AU 8y ago
Circa 1992.
rurban 8y ago
And even in modern CAD systems the GUI makes no sense anymore. Most better ones separated the kernel from the GUI already, where the GUI only serves for random input and as viewer, but the kernel allows scripting to automate tasks. The GUI's became so complicated, it's easier to design by rules and scripts and avoid osnap'ing to random objects lying in the view.
- mapcars 8y ago
  And it should be like this, in the early days of GUI it was a mess and in many places still is, but people understood how to use it properly - eg as a "frontend" part of an application "kernel". So in my view GUI is not harmful, but completely the opposite. It gives you tons, tons of possibilities and improvements. If used sensibely, of course.
  - kungtotte 8y ago
    On my Linux box I'm running the Awesome WM, and I don't see how anything could possibly be better than it (or anything that works similarly, obviously). I open terminals, neovim, etc. in tiling mode with the WM automatically arranging things according to my settings. Much like tmux etc. Firefox opens in full screen on a separate tag, automatically. As does VSCode. If I want to run something that fits best with a floating window style I can set that up on another tag and it's all automatic. I stay in one WM/mode the entire time and move seamlessly between whatever tool I want to use and I use that tool in the manner it's best used in. What could be better?
Osiris 8y ago
Discoverability. CLIs are notoriously bad at discoverability. GUIs, on the other hand, are much better about showing a user what options / commands are available. If you look around, GUIs and CLIs are both around because they are each good at specific kinds of tasks. We use CLIs to remote into servers because it doesn't require much bandwidth and it works with high latency, etc. The right tool for the right job. I don't understand this mentality that people have that one tool is superior to another in all cases (e.g., linux is always better than Windows, open source is always better than proprietary, etc).
- yellowapple 8y ago
  As a counterpoint: a command-line application with a --help option has just as much discoverability, IMO.
- AstralStorm 8y ago
  I remember the days when CLIs had a HELP command built in and accurate enough. Oh and when people read instruction manuals. A decent manual beats a "discoverable" GUI almost always.
  - xg15 8y ago
    > Oh and when people read instruction manuals. A decent manual beats a "discoverable" GUI almost always. Sorry, but nope. You can rant about GUIs all you want, but UX research did yield a lot of actual insights about how people interact with systems and learn usage. From a learning standpoint, RTFM is enormously inefficient and error-prone. You can learn about usage of an application a lot faster if you can use existing knowledge (e.g., leveraging standard UI widgets or menu items) and if the application gives you feedback loops, so you can evaluate what a command did or will do (ideally before it does anything consequential)
    - oblio 8y ago
      What do you mean by that? Didn't you also learn about balls by someone giving a 100 page dissertation into spheroids? After all, all the info you needed was in there!
kiki_jiki 8y ago
What's up with this "considered harmful" being used everywhere lately?
- molf 8y ago
  You disprove your own point, this is from 1992
  - kiki_jiki 8y ago
    I mean, I see it a lot on hackernews.
  - nailer 8y ago
    It's still had a comeback recently And yes it's 80s/90s newsgroup flamebait. The author concedes GUIs are useful, they just want access to APIs.
- saagarjha 8y ago
  It's based on "Go To Statement Considered Harmful", by Edsger Dijkstra: https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful
- davymac 8y ago
  Yeah, I swear this is being posted so often it’s becoming something I’m starting to ignore (kind of becoming the boy who cried wolf) It feels like the more recent versions of these articles are more poorly written. This article, however, was much more reasonable.
saagarjha 8y ago
I think a nice solution for what the author is looking for in a GUI, namely the ability to write a script that controls them, is achieved today by something like AppleScript, which pretty much does exactly that: you can write little scripts that allow you to have basically full control of the application's UI (and in some cases, the parts not visible). So you really have the best of both worlds: a nice, pretty, and simple GUI interface that most people can use, and a scriptable backing that can be queried and manipulated in useful ways for purposes such as automation. Less related: This is from 1998, I believe, but I guess the general date is obvious from the title itself.
- afraca 8y ago
  If I understand it correctly it's actually from 1992. As for Applescript: how precise can we get with it actually? I think when applications use native toolkits Applescript can figure quite much out on its own, but with custom elements (an Electron application), is this still the case?
  - saagarjha 8y ago
    > If I understand it correctly it's actually from 1992. I think you're right–the 1998 is the date it was forwarded, or something like that. > As for Applescript: how precise can we get with it actually? I think when applications use native toolkits Applescript can figure quite much out on its own, but with custom elements (an Electron application), is this still the case? AppleScript can do everything you, the GUI user can do, at least for native applications. There is an API for adding functionality that doesn't map cleanly to a user interface through scripting dictionaries, so from a certain perspective it can actually do more. With regards to Electron, all bets are off: the application only has this functionality if it writes it itself. This is one of the reasons I generally have a distaste for Electron; it really breaks a lot of nice things that the system provides that are nonobvious if you don't use them but really hurt if you do.
    - danenania 8y ago
      While they might not work well with Applescript, Electron apps can be scripted with a tool like https://electronjs.org/spectron https://electronjs.org/spectron.
LandR 8y ago
>That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems. ha! I hope this was tongue in cheek...
- contras1970 8y ago
  why? i mean, i hold the same opinion sincerely. see neovim for a contemporary instance of the same: https://neovim.io/doc/user/starting.html#--embed https://neovim.io/doc/user/starting.html#--embed (--embed, --headless, --listen).
xg15 8y ago
I don't know. I think the original idea for Windows was that services are accessible through APIs on a system-wide message bus (COM) and the various GUIs are simply clients for those APIs. I'd argue that, if that design were held through (and an easy to use universal client for COM had been available) it could have become even more versatile than unix. But of course, that's not what happened... Then, today, we have a new trend where "GUI-only" functions are actually used deliberately to implement security restrictions or preserve business models. And then there is the mess that is "web-based" GUIs...
- dmortin 8y ago
  Maintaining such internal APIs is additional work and since most users prefer clicking in GUIs, companies ditched this approach, because it's simpler and cheaper to create a GUI only tool.
- jimjimjim 8y ago
  the original idea for windows was a gui with everything sending messages to windows, and everything was a window. COM came along much much later.
- de_watcher 8y ago
  > And then there is the mess that is "web-based" GUIs... I am an all-for-native guy (Qt, etc.), but the "web-based" GUIs are actually bearable from the stand point of the developer with a CLI: their data interfaces are HTTP, so it's easy to hook them into CLI tools their graphics are decently accessible through Selenium
  - xg15 8y ago
    True. From an API standpoint, SPAs actually improved the situation a lot: Introducing an API boundary and separating concerns is now a routine part of developing an SPA.
- kyberias 8y ago
  COM is not a "message bus" and the operating system APIs are mostly not COM-based.
Osiris 8y ago
> A precision pointing device that didn't require taking your hands off the keyboard would help. IBM created this for the ThinkPad. I had a Dell D830 with the little mouse between the G/H keys and the left/right buttons just below the spacebar. It was amazing.
- helb 8y ago
  Trackpoint. Still in use on new ThinkPads and some other laptops. IBM/Lenovo even has/had desktop keyboards with it. https://en.wikipedia.org/wiki/Pointing_stick https://en.wikipedia.org/wiki/Pointing_stick
chuckdries 8y ago
Maybe I'm biased because I work on a git GUI, but even if you ignore the discoverability and accessibility argument, I think graphically displaying information is useful. Think about a kanban application - it's just not something that makes sense as a CLI thing. And yes, you could take exclusive control of and draw to the whole screen and use special characters to draw the board, but at that point you're just making a GUI out of text. Usable via terminal emulator does not necessarily mean CLI tool to me, at least within the context of OP's arguments. A lot of the things OP argues have to do with composition. CLI tools are useful in scripts because you can pass them inputs programmatically access and use their output; in this sense, a tool like vim or lynx doesn't fit OP's definition of a CLI tool, they're more like text-based GUIs.
- earenndil 8y ago
  I'm not making any of the arguments; just thought it would be an interesting discussion piece.
  - chuckdries 8y ago
    In this case I was using OP to refer to the content of the post, the 'original post'
- j1elo 8y ago
  Funnily enough, I scroll down the HN frontpage and see: "Taskbook: Like Trello but for the Terminal" I didn't open that yet, but the coincidence just made me smile (if you can call trello a "kanban" board)
  - chuckdries 8y ago
    So the git client I work on has a built in kanban that syncs with github issues, and I work on that part of the application as opposed to the git graph itself - Having dedicated the last 6 months of my life to a kanban, I'd be really interested to see how they solve a bunch of the UX issues surrounding not having a drag and drop pointing device, which in my mind is like the central interaction in a kanban board. Thanks!
casabarata 8y ago
What OP fails to see is that GUIs are 80% of the reason why you see technology all around you. It’s the layer of simplification the vast majority of people need. PCs didn’t catch on until the GUIs were born. GUIs help architects design the same buildings OP lives in. 99% of the stuff in his home were designed and crafted tnx to a variety if GUIs in the process. Having a contrarian view is fine. But keep things in the correct perspective.
- HeadsUpHigh 8y ago
  The author was not against GUIs. The author was against having GUI only apps.
geff82 8y ago
I think the perfect engineering is to build two pieces: the data functionality should be built into a CLI tool that could potentially be triggered by a human or other third party software, and then build a UI on top that mainly interacts with the CLI. Essentially this is the MVC pattern we nowadays mainly talk about in a web context.
Drdrdrq 8y ago
One could argue that web GUIs are the best of both worlds. If done right, user can easily discover new functions and how they are used, while they still allow interaction with other apps through REST API. They can also be used remotely, the HTTP stream can be forwarded through different means (SSH,...), there are standard ways of authentication,... If done right.
panic 8y ago
I always thought something like this would be neat to explore further: https://www.youtube.com/watch?v=gifzjhyBwOc https://www.youtube.com/watch?v=gifzjhyBwOc (warning: contains some intense flashing at a couple points). A GUI is ultimately producing a stream of actions; these actions can be reified as text and displayed. Then you can copy the text to perform the actions again, modify the text, include it in scripts, and so on.
alkonaut 8y ago
Programs should have a UI that make them as useful as possible. For a large client app “useful” means discoverable, efficient. For a small text utility such as “grep” a good UI night absolutely be CLI. I don’t see how someone would argue that a photo editing app, music workstation, IDE, CAD program etc would somehow be better because it had a graphical UI that was layered “on top” of something that was textual? I think some of the Unix people bashing (no pun I intended) GUIs just don’t use programs where GUIs shine. Sure there are cases where a GUI could and should be layered on top, but for complex media apps it normally doesn’t make sense.
- iforgotpassword 8y ago
  I agree, there's always types of programs where one beats the other. I will never argue that a CLI browser, photo editor (if it exists?) or IDE for say Java has any advantage over a GUI. It's the stuff "in the middle" where it gets interesting. Even if you only consider power users or developers, many times the Windows user still resorts to GUI apps either out of habit or since there is no built-in CLI solution to the problem, and if you need to download anything anyways you might just go with a GUI app. But let's take find as an example: as a power user you might want something a little more involved than what the window search GUI offers, but as soon as you end up with something that involves AND and OR expressions a GUI is already subpar, and then you might want to process the files so you need either an "export to text file" function, or the ability to specify a command to execute. And even if the tool offers both, it's still hard to impossible to automate that task. You might find yourself ending up trying a dozen different file search utilities since you find one you manage to actually embed in an automated workflow. My experience is that Windows people just don't automate in many cases, although it's obviously absolutely possible to get all the GNU tools etc. on Windows too. They're just not being used that much.
  - TeMPOraL 8y ago
    > photo editor (if it exists?) ImageMagick. Mighty efficient, if you know what you want to do, and need to do this on couple hundred images.
jf- 8y ago
We’ve already had ‘considered harmful essays considered harmful’ [1], now I’m waiting eagerly for someone to write ‘software development considered harmful’, followed speedily by ‘communication via any form of symbolic representation considered harmful’. [1] https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
oytis 8y ago
I wish the command line approach was used in the WWW. The world would be so much better place if web resources provided REST API as a primary way to access the data and the web UI was only one possible visualization.
nottorp 8y ago
But this is the age when people post video tutorials on youtube to tell you what to type in the CLI...
kd5bjo 8y ago
Also, when you get yourself into trouble with a CLI, you can usually look back through the session history and figure out what went wrong. GUIs often have an undo stack, but there's no real log what you've done.
beobab 8y ago
I know that Microsoft have promoted powershell in their OS, and I believe they tend to build a GUI on top of powershell commands. I'd love an "ouput powershell window", which displays the powershell that a GUI is running under the hood. I mainly write apps that talk to sql, so always try to include a "sql called" debug output in applications that I write for the same reason: It makes it easier for other people (me, when I forget what something's doing) to pick up what's going on.
kartan 8y ago
> Gratuitous distractions from the keyboard only slow down the experienced user. This is true even for GUIs. I used to maintain an accounting software. Everything could be done just with the keyboard. You could use the mouse, but it was optional. People were registering hundreds of invoices a day. That will not be possible if they need to take their hands out of the keyboard, go to the mouse, move it and go back to the keyboard. Web UIs are extremely inefficient. But it is not a big deal as they are designed more for leisure than for the professional. Hacker News or Reddit interface is good enough to write a message like this one. I would like to see which interface use professional Reddit posters. From Russian trolls to /r/hailcorporate professionals need an interface that is not so mouse dependent. The command line it is also a GUI, mine at least allows me to use the mouse to copy/paste text. But it is an optional feature that I don't need to use each time I write a command.
axilmar 8y ago
GUIs are problematic in the same way command line tools are: there is no way to access the internal functionality of both from a programming language. Programs should come in three levels: 1) libraries, so anyone can make a program off them. 2) command line tools, which use the libraries to achieve specific goals. 3) GUI tools, which use the libraries or tools to show a nice graphical representation to the user.
- dnomad 8y ago
  > 1) libraries, so anyone can make a program off them. 2) command line tools, which use the libraries to achieve specific goals. 3) GUI tools, which use the libraries or tools to show a nice graphical representation to the user. I often wonder if this entire notion of a 'program' is not useful. What people really want, I think, are components. Give people components and they can wrap CLIs around them if they want. Give people components and they can drop them into GUI workspaces if they want. Microsoft COM may be pure unmitigated evil... but the vision, the dream, was on the right track. This thing that happens today where developers throw big, monolithic programs at users doesn't really make anybody happy.
deleted 8y ago
[deleted]
kstenerud 8y ago
Building a GUI that consumes a command line interface turns that command-line USER interface into an APPLICATION PROGRAMMING interface, and that's asking for trouble. USER interfaces and PROGRAMMING interfaces are different things, with different, sometimes conflicting purposes and goals. Conflating the two leads to fossilization and confusion for users and application programmers alike. It also causes unnecessary conversion to and from brittle human-readable formats. I'd go a step further and say that software should first and foremost be libraries exposing carefully designed APIs, then have user facing tools (command line and/or GUIs) built upon that.
IanSanders 8y ago
To use most CLI programs efficiently you need to remember commands and parameters to avoid scrolling through man in pursuit of "that one parameter combination I used last month but cannot find in my terminal history". On the other hand I love GUI apps which show which CLI command corresponds to the selected action (zenmap for example).
perl4ever 8y ago
My opinion is that the pattern object -> action is better than action -> object. That isn't necessarily the same thing as GUI vs. CLI, but there is some correlation.

93 points by earenndil 8y ago

Circa 1992.

And even in modern CAD systems the GUI makes no sense anymore. Most better ones separated the kernel from the GUI already, where the GUI only serves for random input and as viewer, but the kernel allows scripting to automate tasks. The GUI's became so complicated, it's easier to design by rules and scripts and avoid osnap'ing to random objects lying in the view.

mapcars 8y ago
And it should be like this, in the early days of GUI it was a mess and in many places still is, but people understood how to use it properly - eg as a "frontend" part of an application "kernel". So in my view GUI is not harmful, but completely the opposite. It gives you tons, tons of possibilities and improvements. If used sensibely, of course.
- kungtotte 8y ago
  On my Linux box I'm running the Awesome WM, and I don't see how anything could possibly be better than it (or anything that works similarly, obviously). I open terminals, neovim, etc. in tiling mode with the WM automatically arranging things according to my settings. Much like tmux etc. Firefox opens in full screen on a separate tag, automatically. As does VSCode. If I want to run something that fits best with a floating window style I can set that up on another tag and it's all automatic. I stay in one WM/mode the entire time and move seamlessly between whatever tool I want to use and I use that tool in the manner it's best used in. What could be better?

Osiris 8y ago

Discoverability. CLIs are notoriously bad at discoverability. GUIs, on the other hand, are much better about showing a user what options / commands are available. If you look around, GUIs and CLIs are both around because they are each good at specific kinds of tasks. We use CLIs to remote into servers because it doesn't require much bandwidth and it works with high latency, etc. The right tool for the right job. I don't understand this mentality that people have that one tool is superior to another in all cases (e.g., linux is always better than Windows, open source is always better than proprietary, etc).

yellowapple 8y ago
As a counterpoint: a command-line application with a --help option has just as much discoverability, IMO.
AstralStorm 8y ago
I remember the days when CLIs had a HELP command built in and accurate enough. Oh and when people read instruction manuals. A decent manual beats a "discoverable" GUI almost always.
- xg15 8y ago
  > Oh and when people read instruction manuals. A decent manual beats a "discoverable" GUI almost always. Sorry, but nope. You can rant about GUIs all you want, but UX research did yield a lot of actual insights about how people interact with systems and learn usage. From a learning standpoint, RTFM is enormously inefficient and error-prone. You can learn about usage of an application a lot faster if you can use existing knowledge (e.g., leveraging standard UI widgets or menu items) and if the application gives you feedback loops, so you can evaluate what a command did or will do (ideally before it does anything consequential)
  - oblio 8y ago
    What do you mean by that? Didn't you also learn about balls by someone giving a 100 page dissertation into spheroids? After all, all the info you needed was in there!

kiki_jiki 8y ago

What's up with this "considered harmful" being used everywhere lately?

molf 8y ago
You disprove your own point, this is from 1992
- kiki_jiki 8y ago
  I mean, I see it a lot on hackernews.
- nailer 8y ago
  It's still had a comeback recently And yes it's 80s/90s newsgroup flamebait. The author concedes GUIs are useful, they just want access to APIs.
saagarjha 8y ago
It's based on "Go To Statement Considered Harmful", by Edsger Dijkstra: https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful
davymac 8y ago
Yeah, I swear this is being posted so often it’s becoming something I’m starting to ignore (kind of becoming the boy who cried wolf) It feels like the more recent versions of these articles are more poorly written. This article, however, was much more reasonable.

saagarjha 8y ago

I think a nice solution for what the author is looking for in a GUI, namely the ability to write a script that controls them, is achieved today by something like AppleScript, which pretty much does exactly that: you can write little scripts that allow you to have basically full control of the application's UI (and in some cases, the parts not visible). So you really have the best of both worlds: a nice, pretty, and simple GUI interface that most people can use, and a scriptable backing that can be queried and manipulated in useful ways for purposes such as automation. Less related: This is from 1998, I believe, but I guess the general date is obvious from the title itself.

afraca 8y ago
If I understand it correctly it's actually from 1992. As for Applescript: how precise can we get with it actually? I think when applications use native toolkits Applescript can figure quite much out on its own, but with custom elements (an Electron application), is this still the case?
- saagarjha 8y ago
  > If I understand it correctly it's actually from 1992. I think you're right–the 1998 is the date it was forwarded, or something like that. > As for Applescript: how precise can we get with it actually? I think when applications use native toolkits Applescript can figure quite much out on its own, but with custom elements (an Electron application), is this still the case? AppleScript can do everything you, the GUI user can do, at least for native applications. There is an API for adding functionality that doesn't map cleanly to a user interface through scripting dictionaries, so from a certain perspective it can actually do more. With regards to Electron, all bets are off: the application only has this functionality if it writes it itself. This is one of the reasons I generally have a distaste for Electron; it really breaks a lot of nice things that the system provides that are nonobvious if you don't use them but really hurt if you do.
  - danenania 8y ago
    While they might not work well with Applescript, Electron apps can be scripted with a tool like https://electronjs.org/spectron https://electronjs.org/spectron.

LandR 8y ago

>That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems. ha! I hope this was tongue in cheek...

contras1970 8y ago
why? i mean, i hold the same opinion sincerely. see neovim for a contemporary instance of the same: https://neovim.io/doc/user/starting.html#--embed https://neovim.io/doc/user/starting.html#--embed (--embed, --headless, --listen).

xg15 8y ago

I don't know. I think the original idea for Windows was that services are accessible through APIs on a system-wide message bus (COM) and the various GUIs are simply clients for those APIs. I'd argue that, if that design were held through (and an easy to use universal client for COM had been available) it could have become even more versatile than unix. But of course, that's not what happened... Then, today, we have a new trend where "GUI-only" functions are actually used deliberately to implement security restrictions or preserve business models. And then there is the mess that is "web-based" GUIs...

dmortin 8y ago
Maintaining such internal APIs is additional work and since most users prefer clicking in GUIs, companies ditched this approach, because it's simpler and cheaper to create a GUI only tool.
jimjimjim 8y ago
the original idea for windows was a gui with everything sending messages to windows, and everything was a window. COM came along much much later.
de_watcher 8y ago
> And then there is the mess that is "web-based" GUIs... I am an all-for-native guy (Qt, etc.), but the "web-based" GUIs are actually bearable from the stand point of the developer with a CLI: their data interfaces are HTTP, so it's easy to hook them into CLI tools their graphics are decently accessible through Selenium
- xg15 8y ago
  True. From an API standpoint, SPAs actually improved the situation a lot: Introducing an API boundary and separating concerns is now a routine part of developing an SPA.
kyberias 8y ago
COM is not a "message bus" and the operating system APIs are mostly not COM-based.

Osiris 8y ago

> A precision pointing device that didn't require taking your hands off the keyboard would help. IBM created this for the ThinkPad. I had a Dell D830 with the little mouse between the G/H keys and the left/right buttons just below the spacebar. It was amazing.

helb 8y ago
Trackpoint. Still in use on new ThinkPads and some other laptops. IBM/Lenovo even has/had desktop keyboards with it. https://en.wikipedia.org/wiki/Pointing_stick https://en.wikipedia.org/wiki/Pointing_stick

chuckdries 8y ago

Maybe I'm biased because I work on a git GUI, but even if you ignore the discoverability and accessibility argument, I think graphically displaying information is useful. Think about a kanban application - it's just not something that makes sense as a CLI thing. And yes, you could take exclusive control of and draw to the whole screen and use special characters to draw the board, but at that point you're just making a GUI out of text. Usable via terminal emulator does not necessarily mean CLI tool to me, at least within the context of OP's arguments. A lot of the things OP argues have to do with composition. CLI tools are useful in scripts because you can pass them inputs programmatically access and use their output; in this sense, a tool like vim or lynx doesn't fit OP's definition of a CLI tool, they're more like text-based GUIs.

earenndil 8y ago
I'm not making any of the arguments; just thought it would be an interesting discussion piece.
- chuckdries 8y ago
  In this case I was using OP to refer to the content of the post, the 'original post'
j1elo 8y ago
Funnily enough, I scroll down the HN frontpage and see: "Taskbook: Like Trello but for the Terminal" I didn't open that yet, but the coincidence just made me smile (if you can call trello a "kanban" board)
- chuckdries 8y ago
  So the git client I work on has a built in kanban that syncs with github issues, and I work on that part of the application as opposed to the git graph itself - Having dedicated the last 6 months of my life to a kanban, I'd be really interested to see how they solve a bunch of the UX issues surrounding not having a drag and drop pointing device, which in my mind is like the central interaction in a kanban board. Thanks!

casabarata 8y ago

What OP fails to see is that GUIs are 80% of the reason why you see technology all around you. It’s the layer of simplification the vast majority of people need. PCs didn’t catch on until the GUIs were born. GUIs help architects design the same buildings OP lives in. 99% of the stuff in his home were designed and crafted tnx to a variety if GUIs in the process. Having a contrarian view is fine. But keep things in the correct perspective.

HeadsUpHigh 8y ago
The author was not against GUIs. The author was against having GUI only apps.

geff82 8y ago

I think the perfect engineering is to build two pieces: the data functionality should be built into a CLI tool that could potentially be triggered by a human or other third party software, and then build a UI on top that mainly interacts with the CLI. Essentially this is the MVC pattern we nowadays mainly talk about in a web context.

Drdrdrq 8y ago

One could argue that web GUIs are the best of both worlds. If done right, user can easily discover new functions and how they are used, while they still allow interaction with other apps through REST API. They can also be used remotely, the HTTP stream can be forwarded through different means (SSH,...), there are standard ways of authentication,... If done right.

panic 8y ago

I always thought something like this would be neat to explore further: https://www.youtube.com/watch?v=gifzjhyBwOc https://www.youtube.com/watch?v=gifzjhyBwOc (warning: contains some intense flashing at a couple points). A GUI is ultimately producing a stream of actions; these actions can be reified as text and displayed. Then you can copy the text to perform the actions again, modify the text, include it in scripts, and so on.

alkonaut 8y ago

Programs should have a UI that make them as useful as possible. For a large client app “useful” means discoverable, efficient. For a small text utility such as “grep” a good UI night absolutely be CLI. I don’t see how someone would argue that a photo editing app, music workstation, IDE, CAD program etc would somehow be better because it had a graphical UI that was layered “on top” of something that was textual? I think some of the Unix people bashing (no pun I intended) GUIs just don’t use programs where GUIs shine. Sure there are cases where a GUI could and should be layered on top, but for complex media apps it normally doesn’t make sense.

iforgotpassword 8y ago
I agree, there's always types of programs where one beats the other. I will never argue that a CLI browser, photo editor (if it exists?) or IDE for say Java has any advantage over a GUI. It's the stuff "in the middle" where it gets interesting. Even if you only consider power users or developers, many times the Windows user still resorts to GUI apps either out of habit or since there is no built-in CLI solution to the problem, and if you need to download anything anyways you might just go with a GUI app. But let's take find as an example: as a power user you might want something a little more involved than what the window search GUI offers, but as soon as you end up with something that involves AND and OR expressions a GUI is already subpar, and then you might want to process the files so you need either an "export to text file" function, or the ability to specify a command to execute. And even if the tool offers both, it's still hard to impossible to automate that task. You might find yourself ending up trying a dozen different file search utilities since you find one you manage to actually embed in an automated workflow. My experience is that Windows people just don't automate in many cases, although it's obviously absolutely possible to get all the GNU tools etc. on Windows too. They're just not being used that much.
- TeMPOraL 8y ago
  > photo editor (if it exists?) ImageMagick. Mighty efficient, if you know what you want to do, and need to do this on couple hundred images.

jf- 8y ago

We’ve already had ‘considered harmful essays considered harmful’ [1], now I’m waiting eagerly for someone to write ‘software development considered harmful’, followed speedily by ‘communication via any form of symbolic representation considered harmful’. [1] https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html

oytis 8y ago

I wish the command line approach was used in the WWW. The world would be so much better place if web resources provided REST API as a primary way to access the data and the web UI was only one possible visualization.

nottorp 8y ago

But this is the age when people post video tutorials on youtube to tell you what to type in the CLI...

kd5bjo 8y ago

Also, when you get yourself into trouble with a CLI, you can usually look back through the session history and figure out what went wrong. GUIs often have an undo stack, but there's no real log what you've done.

beobab 8y ago

I know that Microsoft have promoted powershell in their OS, and I believe they tend to build a GUI on top of powershell commands. I'd love an "ouput powershell window", which displays the powershell that a GUI is running under the hood. I mainly write apps that talk to sql, so always try to include a "sql called" debug output in applications that I write for the same reason: It makes it easier for other people (me, when I forget what something's doing) to pick up what's going on.

kartan 8y ago

> Gratuitous distractions from the keyboard only slow down the experienced user. This is true even for GUIs. I used to maintain an accounting software. Everything could be done just with the keyboard. You could use the mouse, but it was optional. People were registering hundreds of invoices a day. That will not be possible if they need to take their hands out of the keyboard, go to the mouse, move it and go back to the keyboard. Web UIs are extremely inefficient. But it is not a big deal as they are designed more for leisure than for the professional. Hacker News or Reddit interface is good enough to write a message like this one. I would like to see which interface use professional Reddit posters. From Russian trolls to /r/hailcorporate professionals need an interface that is not so mouse dependent. The command line it is also a GUI, mine at least allows me to use the mouse to copy/paste text. But it is an optional feature that I don't need to use each time I write a command.

axilmar 8y ago

GUIs are problematic in the same way command line tools are: there is no way to access the internal functionality of both from a programming language. Programs should come in three levels: 1) libraries, so anyone can make a program off them. 2) command line tools, which use the libraries to achieve specific goals. 3) GUI tools, which use the libraries or tools to show a nice graphical representation to the user.

dnomad 8y ago
> 1) libraries, so anyone can make a program off them. 2) command line tools, which use the libraries to achieve specific goals. 3) GUI tools, which use the libraries or tools to show a nice graphical representation to the user. I often wonder if this entire notion of a 'program' is not useful. What people really want, I think, are components. Give people components and they can wrap CLIs around them if they want. Give people components and they can drop them into GUI workspaces if they want. Microsoft COM may be pure unmitigated evil... but the vision, the dream, was on the right track. This thing that happens today where developers throw big, monolithic programs at users doesn't really make anybody happy.

deleted 8y ago

[deleted]

kstenerud 8y ago

Building a GUI that consumes a command line interface turns that command-line USER interface into an APPLICATION PROGRAMMING interface, and that's asking for trouble. USER interfaces and PROGRAMMING interfaces are different things, with different, sometimes conflicting purposes and goals. Conflating the two leads to fossilization and confusion for users and application programmers alike. It also causes unnecessary conversion to and from brittle human-readable formats. I'd go a step further and say that software should first and foremost be libraries exposing carefully designed APIs, then have user facing tools (command line and/or GUIs) built upon that.

IanSanders 8y ago

To use most CLI programs efficiently you need to remember commands and parameters to avoid scrolling through man in pursuit of "that one parameter combination I used last month but cannot find in my terminal history". On the other hand I love GUI apps which show which CLI command corresponds to the selected action (zenmap for example).

perl4ever 8y ago

My opinion is that the pattern object -> action is better than action -> object. That isn't necessarily the same thing as GUI vs. CLI, but there is some correlation.