4 ms·

Kind of? Text search will also find commented out usage, docu, changelog, and my .org file with refactoring ideas from last month. (For better or worse.) It wil

Kind of? Text search will also find commented out usage, docu, changelog, and my .org file with refactoring ideas from last month. (For better or worse.) It will also show when a class with the same method names exists elsewhere - which you want to know about if the naming is good. To find usage of a method called "update", LSP results will be better, but... that was kind of the point? That you don't name your methods "update" if they are important semantically. 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.

troupo 2y ago
> Text search will also find commented out usage, docu, changelog, and my .org file with refactoring ideas from last month 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-source-code.html#go_to_declaration https://www.jetbrains.com/help/idea/navigating-through-the-s... - go to implementation https://www.jetbrains.com/help/idea/navigating-through-the-source-code.html#go_to_implementation https://www.jetbrains.com/help/idea/navigating-through-the-s... - Find usages https://www.jetbrains.com/help/idea/find-highlight-usages.html#find-usages https://www.jetbrains.com/help/idea/find-highlight-usages.ht... perhaps even inline https://www.jetbrains.com/help/idea/find-highlight-usages.html#usages_hints https://www.jetbrains.com/help/idea/find-highlight-usages.ht... - find the full caller hierarchy https://www.jetbrains.com/help/idea/viewing-structure-and-hierarchy-of-the-source-code.html#ws_build_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.html 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.html 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.
- matwood 2y ago
  I'm glad you mentioned IDEA, so I didn't have to. People rave about LSP and it's great that it exists, but IDEA has been doing more advanced code navigation for years (decades?).
- chikere232 2y ago
  You seem weirdly angry that some other people like to work in a different way than you like to work. People like different things. You still get to like your thing.
  - troupo 2y ago
    There's nothing weird with being annoyed at people who not only have no idea about the tools available to them, but also make no effort to learn about them while patting themselves on the back for it and feeling superior
    - chikere232 2y ago
      Isn't that you feeling superior because of your tool preference? 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.
      - troupo 2y ago
        > It's quite possible to know about a tool and still not like it. 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 :)
        acuozzo 2y ago
        Here are my issues with IDEs. Perhaps you can win me over. #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.

troupo 2y ago

> Text search will also find commented out usage, docu, changelog, and my .org file with refactoring ideas from last month 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-source-code.html#go_to_declaration https://www.jetbrains.com/help/idea/navigating-through-the-s... - go to implementation https://www.jetbrains.com/help/idea/navigating-through-the-source-code.html#go_to_implementation https://www.jetbrains.com/help/idea/navigating-through-the-s... - Find usages https://www.jetbrains.com/help/idea/find-highlight-usages.html#find-usages https://www.jetbrains.com/help/idea/find-highlight-usages.ht... perhaps even inline https://www.jetbrains.com/help/idea/find-highlight-usages.html#usages_hints https://www.jetbrains.com/help/idea/find-highlight-usages.ht... - find the full caller hierarchy https://www.jetbrains.com/help/idea/viewing-structure-and-hierarchy-of-the-source-code.html#ws_build_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.html 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.html 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.

matwood 2y ago
I'm glad you mentioned IDEA, so I didn't have to. People rave about LSP and it's great that it exists, but IDEA has been doing more advanced code navigation for years (decades?).
chikere232 2y ago
You seem weirdly angry that some other people like to work in a different way than you like to work. People like different things. You still get to like your thing.
- troupo 2y ago
  There's nothing weird with being annoyed at people who not only have no idea about the tools available to them, but also make no effort to learn about them while patting themselves on the back for it and feeling superior
  - chikere232 2y ago
    Isn't that you feeling superior because of your tool preference? 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.
    - troupo 2y ago
      > It's quite possible to know about a tool and still not like it. 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 :)
      - acuozzo 2y ago
        Here are my issues with IDEs. Perhaps you can win me over. #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.