3 ms·

“git grep” is pretty amazing for tracking things down.

rhizome31 5y ago
Of course that's what we end up doing in practice, using external tools (CLI or IDE) to work around a limitation in expressiveness of the language. This advice is a testimony that there's indeed a problem upfront :) And it comes short when searching from commonly used names...
- nitrogen 5y ago
  This advice is a testimony that there's indeed a problem upfront Indeed, and the problem is that IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. Reading code and commit history is a much faster path to understanding a system than an IDE's autocomplete. I learned this from Ruby, and it serves me well in C, Kotlin, Scala, PL/SQL, Typescript, etc.
  - maccard 5y ago
    > IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. I would argue the exact opposite. Developers who force tools designed 30 years ago to dictate programming language best practices today are holding back the entire industry. There is no reason for my tooling to depend on my filesystem; imagine if my IDE integrated directly with vcs, and a language server provided both of those tools semantic information about my code, available on any device. Let's not kid ourselves either, utf-8 isn't human readable on disk, it's still a binary-like format.
    - rhizome31 5y ago
      You're right to remind that the filesystem is a metaphor, a model and not the reality of what's going on on the computer. The thing is it's still the common denominator between different IDEs and text editors. IDEs cannot be used in every situation so any professional developer who uses an IDE also knows his way around with a text editor. If we were to come up with a better abstraction than the file system, it would have to be shared between different IDEs for interoperability. My understanding is that Smalltalk was such an attempt but somehow that aspect of it didn't really spread. Are you aware of current progress being made in this area?
oblio 5y ago
That's like someone asking for directions and you giving them a shovel and a introduction to archaeology manual. If someone asks for directions you give them directions or a current map.
- hagbard_c 5y ago
  Well, no, not really. It is more of the equivalent of showing how to read (or where to find) maps instead of pointing out something on one. If the searcher is in a hurry the latter is more helpful, otherwise the former is preferable.
  - oblio 5y ago
    Yeah, but you shouldn't need git grep to find out what something is. I understand using to find out why it's there, but not what it is.
    - devoutsalsa 5y ago
      Personally I find it faster than using an IDE much of the time. It’s super fast and very powerful.
    - sanderjd 5y ago
      Yeah the problem is that grep understands lines of text but not the structure of code. But code should be understandable by a computer program (by definition it has to be at some point) so you should be able to use a tool that understands the structure of the code it's reading rather than just seeing a bunch of lines of text.
sanderjd 5y ago
I did that for many years, then I switched to languages with good static analysis and felt really silly about how many years I had wasted wandering around in darkness.

Of course that's what we end up doing in practice, using external tools (CLI or IDE) to work around a limitation in expressiveness of the language. This advice is a testimony that there's indeed a problem upfront :) And it comes short when searching from commonly used names...

nitrogen 5y ago
This advice is a testimony that there's indeed a problem upfront Indeed, and the problem is that IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. Reading code and commit history is a much faster path to understanding a system than an IDE's autocomplete. I learned this from Ruby, and it serves me well in C, Kotlin, Scala, PL/SQL, Typescript, etc.
- maccard 5y ago
  > IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. I would argue the exact opposite. Developers who force tools designed 30 years ago to dictate programming language best practices today are holding back the entire industry. There is no reason for my tooling to depend on my filesystem; imagine if my IDE integrated directly with vcs, and a language server provided both of those tools semantic information about my code, available on any device. Let's not kid ourselves either, utf-8 isn't human readable on disk, it's still a binary-like format.
  - rhizome31 5y ago
    You're right to remind that the filesystem is a metaphor, a model and not the reality of what's going on on the computer. The thing is it's still the common denominator between different IDEs and text editors. IDEs cannot be used in every situation so any professional developer who uses an IDE also knows his way around with a text editor. If we were to come up with a better abstraction than the file system, it would have to be shared between different IDEs for interoperability. My understanding is that Smalltalk was such an attempt but somehow that aspect of it didn't really spread. Are you aware of current progress being made in this area?

oblio 5y ago

That's like someone asking for directions and you giving them a shovel and a introduction to archaeology manual. If someone asks for directions you give them directions or a current map.

hagbard_c 5y ago
Well, no, not really. It is more of the equivalent of showing how to read (or where to find) maps instead of pointing out something on one. If the searcher is in a hurry the latter is more helpful, otherwise the former is preferable.
- oblio 5y ago
  Yeah, but you shouldn't need git grep to find out what something is. I understand using to find out why it's there, but not what it is.
  - devoutsalsa 5y ago
    Personally I find it faster than using an IDE much of the time. It’s super fast and very powerful.
  - sanderjd 5y ago
    Yeah the problem is that grep understands lines of text but not the structure of code. But code should be understandable by a computer program (by definition it has to be at some point) so you should be able to use a tool that understands the structure of the code it's reading rather than just seeing a bunch of lines of text.

sanderjd 5y ago

I did that for many years, then I switched to languages with good static analysis and felt really silly about how many years I had wasted wandering around in darkness.