Hacker News Reader

Comment by sharpercoder | Hacker News Reader

I hate non-discoverable UI's. The first thing I do with any software, is click through all possible menu's, windows, ribbons, whatever. After some time, I usually get quite a grasp on what the software is capable of. The two notable exceptions are textbased UI's (terminals, dsls, ...) and softwar requiring domain specific knowledge (e.g. geomodeling software, specific 3D modeling software, ...).

I never understood the appeal for terminals. Often (Microsoft's Powershell is a notable exception) the syntax is full of incomprehensible abbreviations, the syntax is wildly inconsistent, the syntax contains hard to remember acronyms...

No, for me, terminals and most textbased interfaces will never be as usable as GUIs.

View on HN

As a generality, GUIs can do only the tasks they were designed to do, and little more. Text-based terminals allow simple composition of tasks into arbitrarily-powerful pipelines.

Terminals might not have discoverability, but in terms of sheer power they wildly outmatch GUIs for many tasks.

Well hopefully this is not a sentiment that continues to grow in the technical community. All nice things have a cost. For all the efficiency gained from the web-view, consider the cost of building the web-view, maintaining it, hosting, and the other myriad of frontend activities. Contrast that process with downloading a few popular libraries, coding up some methods, exposing them via a cli lib, and then publishing to one of the many package managers. I can do the later in an afternoon, but I may never release if I think all my users should have a web-view.

I suspect if all technical users simply stopped considering text based ui acceptable, we'd actually have less quality software overall. There are too many programmers like myself, who can make decent programmatic interfaces, but simply can't put together a usable web-interface to save their life.

If you don't understand the appeal, do you think you should pass judgement? Hate is quite a strong word. Terminal interfaces are quite "discoverable," more so than GUI's I could argue. You can often display the list of available commands, see their documentation, etc. Terminals are universal interfaces to many different types of software. With GUI's, you must learn the different ways people have decided to hide away commands in convoluted menus. I am personally a reformed GUI-holic, so I understand where you are coming from, and know from my refinement that it is a place of misunderstanding.

A command line interface lets you communicate to the computer using language. Learning a language is something you can practise and get better at until you find that you're able to communicate very complicated tasks that the original authors of the programs had never even imagined.

Graphical user interfaces are a caveman interface. You go to the market, see what's on offer, point to it and grunt. That's fine as long as you see what you want. But you'll never do anything that you can't already see.

It's not easy, though. Nobody pretends that it is. But learning to read and write wasn't easy either and you managed that. What if our education systems didn't enforce that? How would you ever know the power you're missing out on?

But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation...

A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared looking to most commandline scripts. It's an incomprehensible mess people only can start to grok after years of experience with the particualr commandline tool.

So? English is horribly inconsistent but you seem to be doing just fine. We know bash etc. aren't ideal. That's why Python was invented. But the reason they stick around is because they are useful and people do use them day to day. Are you really going to forgo language completely just because it doesn't meet your superficial idea of perfection?

Human languages are also forgiving on the receiving side which is not true for computer languages. 1 wrong character and yiu get an error. This is an important difference when discovering and even using it,l.

> But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation...

And how is this different for GUIs? Location / icons / description / ... depends entirely on the application. Some will have hotkey handles, some won't. Same app on a different system will look differently. (Possibly with different layout) Creating a discoverable GUI takes as much will and attention as a good set of CLI options.

With a language, it is far more important. In a gui I can just click around and see. With tuis, I need to enter a command and hope it is the right syntax.

Yes tuis. But clis commonly have a --help option, and/or a man page.

IDK about you, but I find it writing a command and seeing the result is far, far faster than clicking around.

I would spend far less time at my computer (would only use it for work) if it only had a CLI, but I would never, never use a GUI (beyond text editors, of course) for most of the grunt work, the CLI is simply faster and, and this is the most important issue, almost everything you do with it can be automated.

I couldn't even begin to imagine having to navigate the endless dialogues in IDEs to configure every little thing I would do in the command line, I'd give up programming altogether.

Terminals don’t suit this approach of trying to get an overview of what a program does. Personally I find trying to get an overview of a complex program/concept/project/anything quite taxing and laborious. Terminals are a welcome relief from this issue. They are precisely as complicated as they need to be for a given task. A GUI will never have this property.

For CLI apps you wouldn't have to click through all the menus and discover stuff, there should be a man page you can skim to discover it. Even better is that it's searchable, you don't have to click through all possible menus looking for that one odd feature you don't remember in 6 months time.

For full TUI applications I'd agree, there are usually worse at discover-ability, they are used because the make up for it in other ways like speed and learn-ability.

Figure this is a troll post, but I'll bite.

As an example of composability... Say you have an api that returns products, but you want to find out how many have the word aliens: curl # gets the api responses grep # searches input wc # counts input. jq # parse and query json

Streaming those together:

  curl api.myapi.com/products | jq .name | grep 'aliens' | wc -l

You have your answer quickly without thinking (after you know all this cold).

Most of the commands are also mnemonic -r is usually reverse, -R recurse, -a all.

I recently in 5 minutes took the API response from one api and constructed sql queries into a test db for test data using roughly the above method. Another fun, trolling type command, a product manager that wanted daily updates got a scrum.sh that ran on cron and posted summary of what people did on slack.

I don't know how you can work effectively as a software engineer without knowing something about it.

Speaking of discoverability, I commonly use --help with a command/program that I haven't used before. And if it doesn't have that option, I do dislike it for that.

With zsh and a good completion script (e.g. one provided by oh-my-zsh), tab completion will discover every option for a command. And the man page will list all the options as well.

I hate them too. There are a number of things wrong with them, discoverability is one of them but what really gets me is tracking state. Why do I need to guess at the state of things inside my head as I'm running commands, or query the machine to tell me, when the actual state is sitting there in memory the whole time?

Reply on news.ycombinator.com