> but GUI based IDEs are generally useful and easier to use out of the box for development.

This is true, they are much better for discovery and affordance, but as you progress with your tooling and tool usage there is a much higher ceiling on your productivity with other tools and their composability. In my opinion, not putting effort into learning tools ultimately holds a lot of people back from their potential.

I use both and mostly agree, but for me I don’t think the ROI for learning terminal based tooling is there.

They make some parts of text manipulation faster, but those parts of text manipulation take up less than 1% of my time spent working.

Things like debugging, which take up a large portion of my time, are not so nice in terminal based environments

Yes, for things like Node, I do use tools like the chrome dev tools for debugging and such.

But find a terminal first approach leads me to other tools like curl and jq usage as I go. I see coworkers using a ton of time trying to repetitively execute the code to see those spots in really inefficient ways. And end up completely lost when they could be using tools like git bisect.

Or another good example devops type support is if one web server out of many seems to be misbehaving, I can use aws command line to get internal ips behind the lb to curl to grep and find it in minutes after others have tried for hours. It makes it second nature if your mind goes there first.

I work 99% in a terminal and fire up a JetBrains IDE when I need to do deep debugging. It’s so rare for me though that it’s worth more for me to get good at the terminal stuff. I’m sure this depends heavily on the type of work being done, game dev for example really needs a good debugger. That being said, gdb and others have perfectly fine text mode interfaces, albeit with a steeper learning curve.

As always, the “best” tool is the one your most familiar with that gets the job done. Text vs GUI doesn’t really matter at the middle of the bell curve.

> there is a much higher ceiling on your productivity with other tools and their composability

What exactly is the "ceiling" for GUI based IDEs?

Composition. I don’t think there’s any GUI that can be used for the git email workflow.

Versatility. In most TUI editors, running an external commands is easy, including piping a part of the text and receiving its output. As this is a fundamental unix principle, there’s basically no barrier between what you’re editing and other data on your system. In GUI, everything is its own silo.

Presentation. Code is not linear, but most gui forces use to use one window to see your text files. And when they allow splitting it’s cumbersome to use. Vim and Emacs has a easier way to divide you screen so that the relevant information can be presented at once. And there’s terminal multiplexers for simpler editors.

Why would you say GUI based workflows are better (ignoring LLMs for now)? I would maybe give you debugging with breakpoints but for anything else I love my neovim with tmux setup

I spend more time reading and debugging code than writing it.

Vim and other terminal tools make doing complex text manipulation easy, but I rarely need to do anything complex when writing code.

I also work from different machines and ephemeral vms regularly and don’t want to spend time setting things up each time.

I can install vscode and the one lsp plugin I need in under a minute. In contrast, Vim doesn’t even have line number enabled by default.

I don't think setup time is a fair comparison here. Any dev who cares to use CLI tools has a dotfiles repo that sets up everything in "under a minute".

What about installing the tooling needed to make various plugins work (ripgrep, fd, lsps, etc)?

And I work on different types of systems, which have different requirements and different ways of installing these tools.

Yes, there are other tools to help automate this process as well, but vscode “just works”

I mean yeah, there are tools to automate it. I think you may have a point if both of the following hold true:

1. You very frequently have to install your setup from scratch.

2. Preconfiguring something that aids in installing from scratch is not viable or sensible. (Perhaps you work in an environment where you're not allowed access to your personal dotfiles repo, for example.)

But I think most people will fail at least one of these checks.

I find that (neo)vim enable code navigation to be much faster than any GUI as well, once past the learning curve. If you’re going to work with code long term (eg: years), the learning curve pays off quickly.

Lol terminal is better for everything except maybe the one case you mentioned: first time use feature discovery, and that's debatable

That seems a little harsh. GUI tools can give us a more vibrant and useful interface.

But, I think the main problem is that although there have been many attempts we have not gotten to a standard way to compose different GUI tools easily or repeat actions.

I spend half or more of my time debugging and I think I would quit if I were forced to only use terminal based tools.

I am sure you would!

I completely disagree. Terminal workflows are superior in a number of ways. Most important to me are that they are more composable and more customizable. The learning curve is tougher, but the "skill ceiling" on them is higher. The ease and speed with which somebody comfortable in their terminal based environment will navigate through the tasks they need to do will always exceed what is even possible in a GUI.

I would say that GUIs are superior for a few specific use cases, but otherwise sub par. Step through debugging comes to mind as a good GUI use case, but even that I'm not sure if it's because a GUI is inherently better, or making a terminal based debugger is harder and so nobody has made a good one yet.

> Terminal workflows are superior in a number of ways

What specific ways do you find boost your productivity the most?

For me, the things terminal workflows can do faster take up almost a negligible amount of my workday.

Curious to hear if I’m missing out on a terminal workflow, or if my workday is just very different from yours