[not-so-darkstar]

I don't understand the idea to make everything terminal-centric. It should be one component of all the tools available to the programmer.

All text editors worth using have a way to open a terminal for that one time you need it, everything else should be a GUI (with all the advantages that come with it).

[dr_kretyn]

Extremes are on both ends. Some people want to use a terminal for all, some don't want a terminal at all.

I'm a terminal guy because most UI I use is just unintuitive and requires a lot of mouse clicking - using mouse is just inconvenient to me. And often there are no tools for what I want to do, or rather, I'd need to open many tools to do something simple like change a file on a remote machine.

But I like a nice IDE, I use DB explorers, I use cloud code to write GUI for data processing and reporting visuals. Terminal is just a "killer app" that's useful for almost everything. So, if you're using regardless, why not make the experience better?

[not-so-darkstar]

I don't think terminal multiplexers (even Zellij which claims not to be one) make the experience better. They make it worse, actually, because when you have a problem there's one more thing to keep track of: Your terminal emulator, your terminal multiplexer and your TUI.

A decent terminal emulator like kitty solves all of this.

[chrysoprace]

GUIs are often mouse-centric, resource-hungry.

TUIs and CLIs are often keyboard centric only use as many resources as it takes to do the task, and then minimal resources to draw the text. Most CLIs also follow the Unix philosophy of doing one thing well, so you can get an output from a CLI and then pipe it into another.

At work I literally use the same workflow at home across two different operating systems because they both share a terminal. I don't even know how to switch workspace on a Mac because I don't need to, tmux sessions fulfil the same task.

[Barrin92]

>Most CLIs also follow the Unix philosophy of doing one thing well,

basi cli tools yes, but software like the one we're commenting on has a TUI so complex they simply emulate graphical user environments and widgets but on a text rendering stack, akin to web apps pretending to be graphical applications on top of a markup language, except they do it out of necessity because that's how the web works.

If you want to draw graphical user interfaces on an operating system just use the... actual graphics stack. There's terminal apps with widget frameworks now that painstakingly try to reproduce what every OS ships with just because it's.. cool to be a terminal hacker or something?

[mistercheph]

Keyboards are higher bandwidth man-machine interfaces than mouse + GUI unless what you're exchanging is spatial information, which is typically not the case for writing software.

There is a higher learning curve, and we can argue about the tradeoffs you make, but some powerful tools can be difficult to learn to use. Complexity != bad design; sometimes you're just exposing an underlying problem space that can't be simplified without being cut off from part of the solution space.

[homebrewer]

I use IDEA for most things and barely touch the mouse. It has its problems (like terrible performance), but it's a good example of a GUI done right.

Everything can be controlled through the keyboard, typing into every window does fuzzy search of its contents (and that window might contain a list of code symbols, a list of database tables, a list of search results, or many other things).

Every action can be bound to a key combo of your choice. Every interaction with the GUI can be stored as a macro, edited and replayed.

And so on, and so forth.

[grepex]

This 100%. For me, the philosophy is not so much a terminal-centric design but a keyboard-centric design. Sure, this could be done in a GUI, but even GUIs with a keyboard-centric design are not as fluid as a TUI.

I'll also add that (like the parent comment) I did not get the appeal. Not until I forced myself to use it more and saw the benefits.

[not-so-darkstar]

I didn't understand much of you said but it sounded mathy so I'm going to reply with a counterexample, just look up on youtube Russ Cox solving AoC with Acme and tell me that's not impressive!

By the way, using a GUI doesn't automatically using the mouse for everything, think of GVim or Emacs. the problem with terminal emulators is the emulating part, where they are forced to comply with the idiotic rules from the '70s.

[aaplok]

> It should be one component of all the tools available to the programmer.

> All text editors worth using have a way to open a terminal for that one time you need it.

Is this not somewhat self-contradictory? Having the terminal in the editor or having the editor in the terminal are both about having one tool that rules the others. The only difference is which one you choose to be the ruler.

[ghusto]

For me it's because it's because most things are faster, easier, and don't change (what you learn retains it's value, and doesn't become worthless when the new hotness arrives). So for me it's the other way around; everything should be in the terminal, with a GUI for that one time you need it (`open .` on Mac to open Finder).

[not-so-darkstar]

With all the new CLI tools it looks like the opposite to me. For example the ag, ack, rg history.

VS Code still has the same style from 2018.

[tomtomtom777]

It's quite often useful to have multiple tabs or panes in your terminal. Zellij does this. It's a terminal multiplexer, like tmux. Mostly just a bit more beginner-friendly and polished.

So obviously it's terminal-centric.

[hollerith]

I don't even use a terminal to run shell commands.

[not-so-darkstar]

Another fellow GVim user?

[klooney]

The author's father agrees with you, which is pretty funny.