Hacker News Reader

Comment by hawaiian | Hacker News Reader

That the author considers the command line an archaic mode of human-computer interaction makes it difficult for me to take his commentary on Google Duplex, let alone AI and HCI design, seriously.

Secondly, I have a hard time thinking design is anywhere close to obsolete. Google Duplex sounds like an adapter that will make reservations for you upon voice command. This will not obsolesce anything except a few forms on most websites. Design encompasses _much_ more than how a form looks or functions.

View on HN

They don't say archaic, they say "learning to code is beyond the reach of most people", which seems like a fair statement.

My kids learned how to use touchscreens as babies. They learned how to manipulate GUIs around the time they entered school. But they still regard my terminal window as black magic, and I'm not sure how to even start explaining what's happening when I punch in commands.

That said, I agree the article is overstating the impact this will have: computers talking to computers has been a thing for a long time, they just use APIs (which are carefully crafted to be as umambiguous as possible) instead attempting to parse ambiguous human speech and pipe it into arbitrary web pages.

> and I'm not sure how to even start explaining what's happening when I punch in commands.

Though perhaps not trivial, it seems easier than, say, explaining what you're doing when you fix/manipulate things on a car engine.

The terminal uses a form of language to give commands, and the result is the execution of the command and/or some sort of printed output.

`ls -lah` could be explained as 'a fast way of inputting' the equivalent of "Alexa, tell me in detail what files are in this directory". (Yes, you would have to explain something basic about files and directories, but that still seems reasonable.)

FWIW, I’ve given this talk to people unfamiliar to the terminal and they’ve been able to get the gist of how basic things work in under an hour.

That's because finding people unfamiliar with the terminal that are willing to spend an entire hour in front of a terminal learning how to use it is the hard part.

My original suggestion was envisioned as a 3–5 minute explanation.

The problem is that CLIs are undiscoverable. You either know what `ls` is or it's just a bunch of random letters. Your average user will never learn a new unforgiving language just to talk to their computer.

You can try to re-experience that frustration for yourself by playing an interactive fiction text adventure game. For example in http://adamcadre.ac/if/905.html, the first few things I tried were: "left", "go left", "move left", "map", "where am i", "help", "?", "tell me what I can type", "fuck you", "exit" (you've now exited the room and are in the living room)

Sounds like a lazily written cli, typing help in bash gives usefull information and also refers to info. So you get an overview of the available commands and a description of the basics with minimal effort.

Meanwhile I can play hide and seek with the tools I need in Gimp for hours.

Indeed. What if the cli had both natural language syntax, large alias/synonym matching, and command prediction (eg similar to Gmail's recent feature)? That might reduce the non-discoverability issue to about the same as most direct manipulation ui (where you have to look through menus for the "right" item to click on).

Mathematica has something akin to command prediction and it’s also a very nice way to learn the language.

>and I'm not sure how to even start explaining what's happening when I punch in commands.

When you see your kids do something with a GUI ask them to write down a list of instructions so that you can do it too. That list of instructions is basically what using a CLI is, it's just less discoverable.

I'm having a hard time understanding how the author even jumped to the conclusion they're at.

Agreed, though design will evolve to facilitate these sessions. My guess is that it will become more artistically / brand driven and less technical. A designer won’t need to think about the fidgety aspects of the interface and more about the presentation.

Same exact feelings bubbled into my head, but as I thought about it, is it really wrong to refer to a cli as archaic today? I posit that that it’s not when discussing application ux/i design.

It's archaic for general-purpose computing except for a small subset of tasks which nothing can rival it at.

What do you mean by general purpose computing? I would wager that things like "search a file for a string" or "show the first x lines of the file" count as general purpose and even these simple tasks are easier done on the cli than anywhere else. On windows/macos using the regular guis, you will run into all sorts of problems if the file type is not recognized, you will need to open the entire file in some text editor, click through the interface to find the search feature (or memorize how to use it, which is no different from memorizing the cli command), etc.

Unless you can explicitly enumerate the "small" subset of tasks the cli is simply better at, I don't think that's a valid out. The CLI (specifically, the unix philosophy) is IMO the best platform for general purpose computing. It's the specialized stuff, mostly applications with such a large feature/configuration surface that it would be foolish to try to learn all the commands and arguments, that is best left outside the cli.

General purpose for me tends to be a loose definition of communication /media in any form (web pages, IM, video, photos, games..) either consumption or creation.

CLI works incredibly well for anything related to controling systems (local, web servers), or running any kind of processes at scale (web scraping, photo metadata). Discovery is the biggest problem here, though I do believe it's solvable. If I want to do any one-off task, such as resizing an image, that's incredibly easy to locate and do within the typical operating system GUI, whereas to do it in CLI I'd have to resort to man-pages or search engines to figure out what command to execute.

The inverse is true: there is a small subset of tasks where a GUI can be so good that nothing rivals it (everything that needs the graphical part and has to have a real time feedback).

For everything else CLIs are more consistent, flexible and extendible.

But why not use both? GUIs are amazing for editing a video, command line is amazing. If you want to convert a thousand videos into different formats based on their meta data the CLI will be the only option that doesn’t makes you sit there for a week.

I prefer to think of it as eldritch. It can be difficult to master all it's features, but it's one of the few (pseudo) protocols whose age is actually it's strength.

Reply on news.ycombinator.com