Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, thanks. I don't want a mere "user" interface, I want a programmer's interface. I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them.

Here's an example I just pulled out of my shell history:

  c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set
This huge oneliner clears the screen, logs into my laptop via ssh, then logs into my development virtual machine, then generates a patch from the specified commit, and this data gets piped into my Termux terminal and my phone's clipboard. Then I paste it into the ChatGPT app for code review.

I didn't need to think to write this, I just wrote it right there in the terminal using the shell's line editor, just because I needed it, and it completely solved my problem. It's as easy as pressing up on keyboard now, and I can easily turn it into a script if needed. Nobody had to bend over backwards to add monstruous features to the apps to accomodate me. I knew what my computer needed to do, and I made it do it.

In my opinion we need more of this, not less. More unix and less iphones.



From the article

> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.

You're also arguing for CLIs which are absolutely great. But TUIs provide none of the composability of CLIs nor the malleability of GUIs


It's a fine point if made in isolation, but TUIs tend to be more technical and useful simply because they require using a terminal at all. GUIs tend to be made for the non-technical iPhone audience.

So while I'm not fundamentally opposed to graphics, I'm absolutely opposed to the "average user" culture surrounding it. I don't care about the "normal person", I don't want "user experiences" that hide the computer, I want all of the computer's primitives exposed so that I have full control.

https://contemporary-home-computing.org/RUE/


> GUIs tend to be made for the non-technical iPhone audience.

Except for, you know, every serious professional application ever.


Yeah. This is Unix nerd bs and toxic behavior and silly belief that only terminals deliver complex behavior.

I was visiting a radio test lab in last February for our new product. They use a professional software which was written in WPF. The assistant there was flying with the keyboard shortcuts.

I recommend every self-describing Unix or terminal fan to watch videos of photo or video editors / VFX people on YouTube. They are hella fast.


Absolutely true. But the OPs statement is not without merit. While there is a lot of professional software for which GUI is the correct choice, there is also a lot of "GUI slop" which is just a GUI to look good on marketing and to be easier to onboard new users at the expense of long term effectiveness.


If you use the terminal a lot then TUIs keep you there wo the need to manage yet a other window in the OS. For e.g. you can run nvim in another pane in tmux.


Maybe compatibility goes away a with TUIs. But portability, speed, remote access, and less resource usage are still key advantages.


I agree, authors whole "The time has come to re-evaluate terminal and command line interfaces." is weird, if anything we should be moving MORE towards terminal and command line usage.

Another example from recent history, I just wanted a easy way to mount all connected drives, so whipped up:

    lsblk -l | grep -i part | cut -d " " -f 1 | xargs -I{} sudo mount -m /dev/{} /mnt/{} # automount_all
How would you even approach this with a GUI? You'd need something like Automator or whatever is called on macOS, then manually pipe GUI elements together (or some other way?), and finally there is no automated way of actually testing that it works, so once it breaks because the inevitable OS upgrade, you'll need to manually fix it. Then whatever solution you came up with or used, is almost never reusable for other things.

Meanwhile, a shell alias/function just sits there, easy to see what it does, can control anything in your computer, GUI or not (one way or another), lets you build up your own "database" of tools that all compose together (again one way or another) and finally is easy to put under automated testing.


The article is not against CLIs but TUIs.

It’s extra mentioned that CLIs are mostly a good idea but TUIs aren’t.


> The article is not against CLIs but TUIs.

Isn't it against both? Maybe I'm reading it wrong then, because things like these certainly seem against CLIs:

> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders.

> If you haven’t tried your hand at turning one of your 500 throwaway CLIs into a native app, you’re doing yourself a disservice.

Maybe I'm missed something else, but I certainly got the impression the author isn't very impressed by CLIs.


From the article

> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.


TUIs are not CLI programs though. They're GUIs which render in a terminal


The shell's line editor is a TUI. It's a simple text editor embedded right there in the command line. It can even render your shell history by pressing the arrow keys.


Sure yes. A terminal is a GUI. But it's a GUI used to both run cli programs (which can be piped etc) and TUIs (which cannot)


That example doesn't use any TUI.


The line editing in my shell is absolutely an example of a TUI. It's a simple text editor embedded in the command line.


One version of this is "every application is actually a repl with ideas". I do wish the lisp community cared more about GUIs because it feels like there's a huge gap where exactly this sort of extensibility could be merged with precisely the richer sort of visual interaction the article wants.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: