I don't think your logic is off, but I also think that the FrobnosticatorStudio people have a point. The thing is, yes, the terminal gives you infinitely more capabilities but you probably have like, 20 actual things you do regularly? The learning curve makes it a hard sell when those 20 things are probably all you need. Like, sometimes I'll do something like this if I'm in a terminal and I want to find a build script
cat packages.json | jq .scripts
And that's useful if I'm in the terminal, but if I'm in VSCode I'll just do
ctrl-p -> packages.json <enter> -> ctrl-f -> scr
It's actually fewer keystrokes.
I dunno, I've learned that people's workflows are really personal so I'd never tell someone to switch their's, but for me I prefer tools that understand the structure of my project instead of just treating it like text, so IDEs are a preference for me.
I agree that both approaches are equally fast, and I myself did use VS Code at work a lot before the agents became widespread, so I can imagine myself doing either options. The terminal version is still less keystrokes because of the tab completion or reverse-i-search, but that's nitpicking.
> people's workflows are really personal so I'd never tell someone to switch their's
I regularly, especially when working with younger colleagues at work, find myself struggling to look at how slow they are in the terminal, like when they hit the up arrow 20 times to find the specific command in the history. If I have a close enough relationship with a person to make sure my advice won't be considered rude, I'd probably say “Ctrl+R and then type”, or even “let me show you how I would do it faster”, but doing this too often is borderline rude, so sometimes I just watch and feel bad for them.
I've seen it with seniors too. The smartest person I worked with (by far!) used to constantly use the menus in Visual Studio (OG Visual Studio, not code) for basically every operation. It was incredibly painful to watch. Watching him debug was a nightmare.
The second smartest guy I worked with couldn't really type properly. (He'd use two fingers). He was still a fantastic coder.
The thing is though, it kind of didn't matter because the value these guys provided was with their incredibly high intelligence, and the friction with how they interacted with tools was more of an issue on the margins than a big deal.
I think for people solving easier problems than these guys (who were working on legitimately hard problems), like, a webdev fixing frontend code, tools might matter a lot because there's less thinking and more navigating and typing. So context matters here a lot. But I definitely don't think you get to be an amazing programmer by CLI mastery (it definitely helps, but it's not a requirement)
I have used and use both regularly. The IDE makes the normal stuff really fast, but the CLI enables things that just can't be done in the IDE. I quite often ended up being the guy that dealt with things quickly, especially in an emergency. I just had the tools to get things done quickly, even when I hadn't been in that situation before. And I say that without even being good at awk and sed, which are used a lot by others in those situations. I always meant to get good at them, but never did. I ended up using other simpler tools instead to get the same kinds of things done.
In short, knowing the CLI way is absolutely useful, even if you use the IDE for 95% of stuff. And I also don't recommend going full CLI, because the IDE way is faster for that 95%.
Most things in life are about balance, and that's true here, too.
My usual thought on this is that I don't want to get stuck at ctrlp ctrlf level. I always pick a tool that gives an intermediate expressiveness level even if it means a bit more efforts.. especially if it's not gui because I can reuse and compose it.
For instance jq falls too far on the capabilities curve. It's a nuclear weapon but it's almost a programming language and I never can keep the operators in mind (even though I loved the idea at first).
It is a programming language. That thing you write between single quotation marks when you invoke jq is a program. (And like with other programming languages, it's often useful to write your jq programs to files instead of always writing them inline in the shell.)
I love jq, though. It provides an extremely good language for its task, even if I often have to take a look at the manual when writing an interesting jq program.
fwiw, Clojure pretty much replaced jq in my toolbelt. Dealing with EDN is so much gratifying - it's almost twice more compact than JSON, it's far more readable; filtering, grouping, sorting, slicing data is so much more straightforward and actually composable, not to mention that I get to do that interactively, directly from my editor.
My shell is configured to show me previews of commands that match from my history. Depending on how long ago I typed the cat command, it might be "cat -> tab -> return"
> I prefer tools that understand the structure of my project instead of just treating it like text
... but in the example you gave, did you not just have it pull up the text contents of a file in a window, and search through it (visually) as text? And on the command line, did you not invoke `jq` specifically to parse the JSON file as JSON?
And really, there is no reason that a TUI pager can't have progressive search that highlights matches. For that matter, vim actually does it. On the other hand, if you're just trying to jump forward to a named unique section, then the appropriate comparison is
> less packages.json <enter> -> /scr
Sure, `less` is more keystrokes than ctrl-p. But you're doing it in a much more general environment (it has to select from every program on your path), so of course it is.
I dunno, I've learned that people's workflows are really personal so I'd never tell someone to switch their's, but for me I prefer tools that understand the structure of my project instead of just treating it like text, so IDEs are a preference for me.