
GUIs Considered Harmful (1992) - earenndil
http://porkmail.org/era/unix/guis.txt
======
Osiris
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).

~~~
mahkoh
_> GUIs, on the other hand, are much better about showing a user what options
/ commands are available._

In general this is only the case if the user is browsing and not looking for
anything in particular. That is, when the user is trying to learn about the
program in general.

If you're trying to find anything in particular, that thing might be hidden in
an options window in a submenu of a submenu somewhere. The only effective way
to find it is to google for the functionality and to hope that someone else
has already asked the same question. This is my experience with Inkscape.

A well written, flat manpage can have much better discoverability than a GUI
with poor or hard to search documentation. Bad manpages are of course
considered harmful.

~~~
iforgotpassword
Yes this is a big plus for CLI. I don't know how many times "something --help
| grep keyword" has immediately solved a problem while for GUI apps you always
need a google search. I mean it's not really that bad, you always have the
browser open anyways and 99% of times someone had the same problem before, but
still, it just feels cumbersome.

~~~
simongray
In most GUI apps on the Mac you can do this kind of thing through Help >
Search..., though.

Not sure about other platforms, but I sure use that feature a lot in e.g.
intellij.

~~~
dotancohen
I was going to mention PyCharm. The Jetbrains editors (intellij) are about the
only GUI app that I've ever replaced a CLI app with and been happy. Their
discoverability and documentation played a big part in that.

------
chuckdries
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.

~~~
j1elo
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
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!

------
alkonaut
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
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
> _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.

~~~
iforgotpassword
Sure, I was more thinking of hand tuning a photo (retouch, cover up, remove a
person in the background). But even if you just tweak contrast and brightness
a GUI probably still wins if you don't know the exact values you want to apply
beforehand.

But batch processing on its own is another great example where CLI shines.
With GUI apps you have to rely on the app shipping that feature, and then it's
almost guaranteed it works slightly different in every app, has different
semantics, hidden in a different spot etc. On the command line, the batch
processing is external to the tool doing the processing, constructed using
features of the shell, so once you understood how to batch process with one
utility, you can do it with everything.

------
kstenerud
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.

------
beobab
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.

------
saagarjha
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
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
> 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
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).

------
jf-
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)

------
xg15
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...

~~~
de_watcher
> 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
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.

------
kartan
> 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.

------
geff82
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.

------
LandR
>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
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).

------
axilmar
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
> 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.

------
meta_AU
Circa 1992.

------
Drdrdrq
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.

------
rurban
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
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
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?

------
IanSanders
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).

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

------
Osiris
> 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
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)

------
perl4ever
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.

------
kd5bjo
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.

------
oytis
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.

------
panic
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.

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

~~~
molf
You disprove your own point, this is from 1992

~~~
nailer
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.

------
casabarata
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
The author was not against GUIs. The author was against having GUI only apps.

