Live data from Hacker News

You Don't Need a GUI

github.com

421–430 of 439 posts

Re: You Don't Need a GUI

#421
post #118

Earlier quoted context omitted.

> Name one thing that a GUI program can't handle, I dare you. Pipe input/output between programs. Chaining cli tools is essential for my work and personal usage. > Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least. That's observably not true. Why didn't you just type out the name?

Because it is obvious, but apparently not to the HN crowd. Let me name it then. Game industry, it's bigger than both music and film industry and it runs exclusively on GUI. Even text based games are GUI actually, not CLI.

A UI presents a structure to enable the user to query and manipulate objects.

A CLI represents that structure by accepting textual commands and presenting output textually.

A GUI represents that structure by displaying objects graphically, showing their spatial representation and connection.

And, traditionally, a GUI tends to show more structure up front while a CLI simply prompts you for a command.

The distinction isn't perfect, but a text adventure game is well inside the CLI camp.

Re: You Don't Need a GUI

#422

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…

A fair part of what I do includes ERP implementation project work. Way back, when TUI/keyboard centric ERP system dominance was starting to give way to GUI/mouse centric ERP systems, I was working with one client where replacing a TUI with GUI based system. One measure we made during the project was the impact to new employee training time and we saw significant reductions in training time due to the sorts of discove…

Out of curiosity, what's the practical difference between TUI and GUI when it comes to discoverability? The kinds of TUI I'm familiar with - mostly from DOS, so stuff like e.g. Borland IDEs (and various third party apps written using Turbo Vision), FoxPro, and VB for DOS - are essentially the same as GUI in that regard; you get a drop-down menu on top, windows with various widgets, often a help bar at the bottom and/or context-sensitive help with F1 etc.

Re: You Don't Need a GUI

#423

Earlier quoted context omitted.

A fair part of what I do includes ERP implementation project work. Way back, when TUI/keyboard centric ERP system dominance was starting to give way to GUI/mouse centric ERP systems, I was working with one client where replacing a TUI with GUI based system. One measure we made during the project was the impact to new employee training time and we saw significant reductions in training time due to the sorts of discove…

What about a system that shows actions in a GUI as a list of equivalent plain text commands. New users would have the discoverability of a GUI while being able to see what goes on command-wise. With time they would be able to convert to plain-text commands and scripting for increased efficency.

FoxPro worked like that. The language itself had commands for various IDE actions, like editing a source file (MODIFY PROGRAM ...) - these worked everywhere, but were really meant to be used in the Command window, basically a REPL. And then if you use the GUI to do the same thing - e.g. File -> Open - it would simply execute the corresponding command in the Command window.

This worked surprisingly well. New users mostly stuck to the menus to discover things, but then gradually switched over to commands for common actions, because they were faster. It also helped that the Command window had context-sensitive help, so once your menu action generated the corresponding command, you could easily open the manual page for it to read up on the details.

Re: You Don't Need a GUI

#424
post #401
post #193

Earlier quoted context omitted.

While not entirely matching your vision for this, TLDR [1] does provide for a similar functionality (discoverability of functions of specific applications). This doesn't help when you want to map the fuzzy idea of performing a specific action to a particular existing program but it has helped me avoid having to search online for how to perform a particular task with ffmpeg. [1] https://tldr.sh

I was not aware of tldr. Thanks! However I think the tldrs need to be sorted better. When tldr git, the first example was Check the Git version: git --version Shouldn't the tldrs show me how to add, commit, push? Who knows. I think the tldr lists should be interactive and allow you to select by pressing 1-9. And maybe it should re-sort based on what you use most often, hehe.

Yeah, it would be neat if it made it a bit easier to work with. Git's TLDR page actually breaks it down through subcommands.

    tldr git commit
will show examples and explanations for using `git commit`.

Re: You Don't Need a GUI

#425
post #118

Earlier quoted context omitted.

> Name one thing that a GUI program can't handle, I dare you. Pipe input/output between programs. Chaining cli tools is essential for my work and personal usage. > Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least. That's observably not true. Why didn't you just type out the name?

Because it is obvious, but apparently not to the HN crowd. Let me name it then. Game industry, it's bigger than both music and film industry and it runs exclusively on GUI. Even text based games are GUI actually, not CLI.

1. The game industry obviously is not a single business.

2. Every single company in that industry uses cli tools.

Both assertion from your original statement are incorrect. What’s your beef with the command line anyways? It’s just an interface.

Re: You Don't Need a GUI

#426
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…

`tldr` has been very useful for me since I discovered it.

Re: You Don't Need a GUI

#427

Earlier quoted context omitted.

> Can you explain more clearly what you mean? I can try ... Specifically, given a command that produces a list of "everything that can be done with the file", how do I cause the (unstructured) text of that list to be piped into a arbitrary other program, in the same way that `grep foo a.txt | bar` causes a list of occurences of 'foo' in a.txt to be piped into arbitrary program bar. > How do you pipe the output of cp…

Ah, thanks for the clarification, it definitely cleared up what you mean. As I understood the suggestion re. file actions it is meant as some sort of interactive completion. So if I type the name of an image file and press tap, I am given the suggestions or options about resizing, format conversion etc. Several shells already have interactive completion of file names. And I think that pattern makes sense from an expl…

Update. I tried the `file -u` example you gave above and the `-u` flag doesn't exist in my version of `file`. I also find it a bit hilarious that the example lists `ed` as the editor of choice.

Re: You Don't Need a GUI

#428

I'm not sure if this is satire or not, but certainly the single worst case of using a terminal is file manipulation. Nothing will ever beat the right-clicks or Ctrl+C/Ctrl+V combos. It's just more natural to "see" things that you move. Now when it comes to more complex applications, I'd stop using the CLI if I had to search the manpages or the internet each time for doing something I already did previously. Since I d…

Really.

OK, rename all files ending in .foo to end in .bar instead. With the GUI.

Re: You Don't Need a GUI

#429
post #381

Earlier quoted context omitted.

That's apple's problem. I've been fixing apple devices since the puck mouse. They choose to go against the grain on purpose. Sometimes it makes sense and sometimes it makes absolutely none.

...and, to build on this: the fact that this is Apple's fault means that it's not the fault of the GUI paradigm - just Apple's implementation of it.

It means it's not the fault of the Windows 95 GUI paradigm most middle-class North Americans millennial age or younger have been trained with. Windows 95 is not the GUI paradigm, it's one single product that implements a GUI paradigm.

Re: You Don't Need a GUI

#430
post #217

Earlier quoted context omitted.

what do I do apart from searching on the internet? On a real UNIX like HP-UX, IRIX, Solaris, FreeBSD or illumos (and any of its distributions), you'd run catman -w as root only once for the lifetime of the system, then run: man -k "disk space" and then you'd search for SEE ALSO with "/", eventually you'd run into df(1), under the very bad presumption that it isn't the first hit. EXAMPLE (Solaris 10, identical for ill…

> real UNIX [...] real UNIX [...] real UNIX Yes, we get it, you hate Linux. Your user profile page says as much. Get over it.

Never! And Linux will go out of fashion soon anyway, as is the norm in IT.
Post reply on HN