Personally, my recent work has been: short term freelance work, new code bases, a variety of programming languages including ones I haven't previously used, problem identification and solving, and mature code bases where you'd only write a couple lines of code a day.
In that context an IDE optimizes a tiny part of the work, while getting in the way for everything else.
I'll add that when I worked on a greenfield Java project as part of a large team, I absolutely used an IDE (IntelliJ at the time) and couldn't imagine working differently.
I don’t think VSC is a very good IDE though. I have no idea why a Vim user would use it instead of upgrading to Neovim, and obviously doom emacs is the best choice but I do think the terminal is actually pretty good in VSC. At least on Windows.
As someone who has only used inferior IDEs to VSCode (grimaces at the thought of Xcode) and who thinks that VSCode is very good, what exactly am I missing from better IDEs?
That being said, use what works for you.
rg string | fpp
git status | fpp
git diff head~1 | fpp
And with Zsh suffixes you can even drop the pipe.And find/grep are very bad and limited tools for this compared to what an IDE will give you
And rg also works in projects with multiple programming languages (e.g. you're using a method from JS and want to find its Rust implementation in the webassembly module) and across project folders (instead of pointing you to a read-only copy of an installed module). But, if you spend 95% of your time in a single codebase with a single language... YMMV.
Yes, when searching across the entire project for text an instant fuzzy search is an invaluable tool.
> It will also show when a class with the same method names exists elsewhere
Oh, this is a great example when a code-aware tool is better. I also ave a rant-ish about LSP at the end.
So, let's say you have several methods called `update` across your codebase. As per original comment, "I rarely need to find only the definition of a function, but rather other call sites too".
With text-search you will find all those other methods, and all the call sites for those methods. And not just in the working code, but across all tests as well. So you have to manually go through the search results and figure out whether a call to update is the one you're looking for.
In an IDE it's just a shortcut:
- go to definition https://www.jetbrains.com/help/idea/navigating-through-the-s...
- go to implementation https://www.jetbrains.com/help/idea/navigating-through-the-s...
- Find usages https://www.jetbrains.com/help/idea/find-highlight-usages.ht... perhaps even inline https://www.jetbrains.com/help/idea/find-highlight-usages.ht...
- find the full caller hierarchy https://www.jetbrains.com/help/idea/viewing-structure-and-hi...
And so on.
Oh, you want to know where all the methods called `updated` are defined to go and scream at someone?
- Search for symbols https://www.jetbrains.com/help/idea/searching-everywhere.htm...
Of course all that is also integrated with things like refactoring. So if you rename a method, you don't have to painstakingly manually search for all invocations of that method. Or if you rename a parameter to that method, or... See the several dozen possibilities here: https://www.jetbrains.com/help/idea/refactoring-source-code....
----
Here comes the rant.
The whole "text searching is enough, the compiler will pint to me the errors I've made" fashion has held back tool development by several decades. It's telling that LSP (which has barely 5-10% of IDEA's functionality) has taken this world by storm. Suddenly the languages and the editors that lacked even the basic quality of life improvements when working with code got a glimpse of what is possible.
Welcome to the very early beginning of the 21st century. Perhaps in 20 more years you will finally let go of the notion that painstakingly doing a computer's job is not in any way or form productive or indicative of a great programmer somehow [1]. And that to work with code you really want tools that are capable of working with code.
After all, somehow, you reach for Excel/Numbers/Google Sheets to work with spreadsheets, for Photoshop/numerous alternatives to edit photos etc. You don't reach for some generic vaguely-adjacent tool to do the job.
[1] I keep telling this story: About 5 years back I saw several people switch from vi/emacs to PHPStorm/IDEA after watching me zipping through code (including jumping from Symfony configs to code and back) while they spent often minutes doing fuzzy searching through the codebase we were working at the time: a huge legacy monolith we were slowly refactoring and splitting up.
It's quite possible to know about a tool and still not like it. Some people liked microsoft's Clippy, and some other people didn't and it's hard to say that either of them were wrong in what made them moste productive, respectively.
My experience with people bashing IDEs has universally been: they've never tried them, or tried for at most a few days. You can immediately see in their comments.
Could be I was exposed to too many such programmers :)
#1. If I decide to migrate from 20 years in the shell with vim & friends, I only want to have to do so once for at least another 20 years and I don't want to use different IDEs for each language I use. I regularly do embedded work in C & aarch64|x86_64 assembly and write applications in both Java & Python. (Yes, I write Java in vim.) I've recently started working with hardware design in Verilog as well.
#2. I prefer to learn the tools I use very deeply, but I learned all of the ones I use now when I had all of the time in the world for yak shaving: high school and university. I have available to me now only a small fraction of the time which was available to me then, so the path to mastery should not be very steep.
#3. Intuitive keyboard navigation of the entire interface is a must. Jumping back and forth to using the mouse feels incredibly uncomfortable to me. It breaks my train of thought just like having an itch which comes right back after having just been scratched would.
#4. The IDE should not rely on an internet connection as I often develop on completely airgapped LANs.
Obviously a developer not using LSPs can be competitive against someone who doesn't (though that's not always the case).
Though if someone is truly bothered by others tool preferences, they should take comfort in the thought that if things really are as they believe, then these people should be driven out of a job for failing to keep up with the times. "Great," you should think, "one less person of competition on the market."
Or Cmd+Click/Ctrl+Click in an IDE
On unfamiliar codebases a mouse with back and forward buttons can be quite a fast and convenient way to get the "lie of the land".
I often do this inside GitHub's browser-based editor.
Yes, using the vimium extension. My only problem is text inputs like this one, my muscle memory expects vim keys to work and I type a lot of jibberish that I have to clean up. I know there are extensions for that too but I can live with it.
(I use a Superior Technologies trackball because it's the only mouse I could find manufactured in the USA and it's really not very precise, it's kind of a self handicap to nudge me towards keyboard shortcuts, muscle memory gains just have a steeper curve on keyboard than mouse)
With the keyboard there is no such coordination, I simply think the thing i want to happen and press the appropriate keys.
In fact, with lsp you wouldn’t even write the error in the first place, saving you a big context switch to the terminal, running the compiler, reading the error, reading the file name, swapping back to edit, focus on the file again.
*Hell