Live data from Hacker News

You Don't Need a GUI

github.com

141–150 of 439 posts

Re: You Don't Need a GUI

#141
post #130

GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate (how many people are doing UI testing? there is a good reason it's not many -- it completely sucks) TUI/console is very good for interoperability…

I totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag. Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications…

There are shells that help with discovery. And auto completion helpers. These are great. You might infer from documentation. There was a big thing about spacial awareness years back, my brain works well like that, familiar brain paths for controls in certain places. But that relies on repetition. I pretty much always forget shell incantations. So any helper tools are a boon for me. Self described to GUI or richer UI would be welcome. If it's not already done.

File explorer multi pick is the thing I desperately claw for for a pointer.

Re: You Don't Need a GUI

#142
post #58

Once learned the GUI actions are impossible to forget. Being away from the computer for two weeks will make you forget 80% of the CLI commands from the author's list. The reason is simple: the brain can associate the GUI actions to many concepts from the real world. CLI concepts exist on computers and nowhere else. That knowledge is too abstract and too expensive to be kept unused in our brain's cache non-stop.

Your brain, is not everyone's brain. FYI

Re: You Don't Need a GUI

#143
post #106

I think this document is a bit too belligerent. "STOP DOING xxx". Really, users should be free to do as they wish. I prefer using console a lot (though I use GUI a lot too!). But I wouldn't force others to do so. Educating them how (if they're interested) is a great thing. Making it sound like they're doing it wrong is not. PS: One thing where a GUI really shines is picking a bunch of files from a folder and moving t…

100% agree with everything you said. So many people use gatekeeping around using CLI, it's crazy frustrating. Use what you're efficient at for the job at hand.

To expand on your example: for a lot of readers of HN, moving all JPGs in a bunch of folders is going to be easier and faster with a CLI. But for who needs to do it very rarely, it's probably still going to be faster for them to navigate folder-by-folder in a file explorer, sort by file type, shift+select, repeat, than it is to learn how to use CLI to do it.

For technical people, GUIs also reduce burden, and let us be lazy. I "know" (or at least once did) how to configure Samba by hand, but for the last many years I've run OpenMediaVault at home and use the UI to do it for me. I don't use Samba for anything else in my life or work, so why do I want to remember or even spend the time reading the manual when I need to make a change to it once a year or so? I'd rather just log into the UI, click a few things, and be done. Nothing to actually remember, as the GUI gives me enough information to figure it out as I go.

I spend a lot of effort to be lazy. If I was regularly moving JPGs out of a folder, I'd probably go further and write a shell script or alias, or even just make a cron job to do it for me; likewise I'm happy to install/use a GUI app for certain things if it means I save time vs reading man pages or having to remember arcane commands I rarely use.

Re: You Don't Need a GUI

#144
post #130

GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate (how many people are doing UI testing? there is a good reason it's not many -- it completely sucks) TUI/console is very good for interoperability…

I totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag. Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications…

I don't think there is a club to be in, but if you want to feel in the club about such things, just say something like "I expect that there is an option for like '-w whatever_madeupoption' that is useful here, but I'd have to take a look at the man page or use '--help' to know for sure". Be prepared to respond to "how would that work?" with APIs/syscalls/etc that you might use to implement that or say something like "I'm not sure, it sounds like an interesting problem if I had time to solve it"

Re: You Don't Need a GUI

#145

As much as I like the command line, I couldn't help noticing from the first 10 or so entries[1] that the "stop" text consists of one of: 1. Drag and Drop 2. Right clicking 3. Ctrl-C and Ctrl-V So these 3-5 things do everything in the list in a GUI, and instead the author wants us to learn 35 different command/syntax combinations? As an aside, I'd like to write an article saying "You Don't Need Github To Write an Arti…

Agreed. But flashy title aside, it’s probably a nice page to send to someone looking to get started in the terminal.

Re: You Don't Need a GUI

#146
post #130

GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate (how many people are doing UI testing? there is a good reason it's not many -- it completely sucks) TUI/console is very good for interoperability…

I totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag. Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications…

The practice you recommend was basically codified as IBM Common User Access, now recognized by some as the UX convention of IBM mainframe software --- one component of CUA was a list of available actions and their assigned function keys, at the bottom of the screen. CUA itself was not widely used, but was highly influential in IBM's greater orbit of software vendors, including Microsoft. As a result, many, but not all, Windows GUI conventions and keyboard shortcuts come from CUA, and this is its lasting legacy.

That CUA was originally defined for text-mode applications as well, and indeed was based on loose conventions that had emerged within IBM for text-mode applications, has been largely forgotten. But even in the '80s there was an appreciable divide between the IBM paradigm, which was more oriented towards menus and actions (what we think of as GUI today), and the AT&T/UNIX paradigm, which was more oriented towards composition of commands.

Of course there are things like newt which have crossed the lines, but generally speaking UNIX derivatives such as Linux have tended to "stay in their lane" of command-oriented environments with minimal user assists. This could be seen as a long-lasting influence of the different I/O paradigms these platforms tended to feature in the influential '80s: UNIX systems were built around line input and output (e.g. TTYs) while IBM systems of the same era were more often built around video terminals (e.g. CRTs). This was basically because UNIX was predominantly running on hardware of opportunity (e.g. whatever the institution already had), and thus had to be flexible and not assume much, while IBM systems were more often used with terminals leased from IBM along with the machine and thus could assume the latest era of video terminal capabilities.

And then, of course, sometime around the '90s all of these platforms more or less ossified in their differences from each other, as each respective camp came to view their UI paradigm as a core feature of the platform which should not be modified.

This is just one of the ways in which UNIX and its family are much more "line-oriented" than even many of their contemporary competitors. This was partially by necessity but also partially by design as the line-oriented paradigm was easy to understand and work with, conceptually if not in practice. Ironically line-oriented input and output is often justified as being reminiscent of punched cards, when the software lineage with a far longer background in punched paper media (IBM, CDC, etc) were far quicker to get away from this model of human-computer interface than UNIX.

Put more generally, "GUI" vs "TUI" is to some degree a false dichotomy. Many of the real capabilities and interactions we associate with GUIs are also quite possible in TUIs (although the GUI version is clearly a refinement), and indeed were often implemented prior to the common availability of raster displays. When people talk about "GUI" vs "TUI" they are almost always actually talking about differing fundamental UI paradigms, which I might call action-oriented and line-oriented. Each can be implemented in a raster-mode or text-mode environment, although both generally work better in a raster-mode display (we might consider Jupyter to be an example of a line-oriented paradigm on a raster display).

Re: You Don't Need a GUI

#148
I am not going to debate this topic, but one thing I will say is that I constantly think about how ridiculously long it takes to make a GUI application compared to a CLI application. It takes at least 10x as long. Large companies can just hire more people, but as a single full-stack person, I just hate the fact that I could make 10 CLI applications in the same amount of time as I could make 1 GUI application.

Surely this has to be discussed at some point.

Post reply on HN