Hacker News Reader

Comment by rvz | Hacker News Reader

I know right. The same old UNIX crustaceans still want to relive the glory days of 1970 with "Everything should live in the terminal" with the chaos of X11, spending countless time editing their dotfiles or starting silly 'Vim/Emacs is better' wars. That ship has sailed. If not, already sunk.

I found this toy to be very cute. Too bad my friends are not the typical software engineer that can use this. I'll just point them to a native macOS habit tracker on the app store instead. Friendly enough for them and efficient enough unlike the Electron alternatives.

Actual progress rather than re-creating the prehistoric 'good old UNIX days' or turning the users laptops into stove burners with many Electron apps running.

View on HN

The more I lean into using the terminal and emacs for programming, the more productive I find myself becoming. I can learn one command-line tool and apply it to so many other things by way of the pipe.

In GUI-land, this is hardly ever the case. I can't compose different software together, which is something I do all the time with the shell.

There are certainly some tools that work better as GUIs, but there are also tons and tons that really are great as terminal tools. No, this may not be a very approachable design for the average non-terminal-user, but that doesn't mean we should decry those who will find it useful. It's okay for different people to use different things.

I think I don't agree with the top-level comment in this thread that "everything should live in the terminal", and instead I believe what another response to that comment said: "everything should be exposed to the shell". Being able to compose tools is a huge productivity gain for those of us who care to do it and are used to it.

Hardly ever the case in GUI-land? That doesn't sound right at all. You can do the same kind of piecemeal work with GUIs that you do in the command line. Unless every piece of GUI software you use has a proprietary file format (which isn't unique to GUI software) it's all composable. Photos, videos, text files, etc. are all interoperable.

One contrived but possibly very common workflow for video creators: snip out a piece of a video with one tool, record new video from webcam with another, edit an image with photoshop, create sound effects in sfx util, create/record music with another, import all of the above into video editor and export a composited/rendered out video, do more lossless video compression/reduction with another utility.

Things I cannot easily compose:

- Messages (macOS)

- Slack

- web browser

- various notes apps

- iTunes

- Discord

- plenty more

These are tools I use all the time throughout the day. There is no simple pipe-like interface that allows me to easily take the output (graphical display) and pass it elsewhere to do something with it. In the terminal, everything shares a universal output system: text.

GUIs are not composable in principle. Sure, there are some workflows where you can do it, but that is not generally the case because they lack this common interface as a standard. CLI tools, on the other hand, have the standard of text output.

Except when those CLI applications happen to use curses, conio, or TTY escape codes for their output.

It is like the "Everything is a file", except when it is not.

Right, my point is that most CLI applications use text as output, versus most GUI applications do not.

Saying "Your point isn't true when there are exceptions" is a lazy argument, honestly. It is overwhelmingly the case that CLI applications use text as output, and my original point was specifically about how I wish this were more often the case with GUI applications — that you could somehow interface with them and compose them in the same way you generally can with CLI applications.

> In GUI-land, this is hardly ever the case. I can't compose different software together, which is something I do all the time with the shell.

Assuming those programs have been written to be usable from the CLI to start with.

Likewise GUI applications can be written to be automated by REPL environments automation, specially if the OS exposes application IPC like COM, DBUS, XPC, Binder, REXX, ....

Reply on news.ycombinator.com