Comment by thwarted
1 year ago
The shell is my development environment. I open up new terminals and shells willy nilly. I find cli tools like find/fd/grep/rg are useful because I rarely need to find only the definition of a function, but rather other call sites too, to find out how it is being used. I think being surrounded by the code and being able to slice and dice it leads to a certain kind of familiarity that a tool that takes you right there doesn't afford. I like fast compilers, and type checking, so it doesn't matter if I can remember the types and fields. I'm not bothered by error messages or warnings, I fix them and I have a greater understanding of the code I'm writing. My editor is a pretty stock vim setup with format-on-save and syntax highlighting, but I can operate without those (in fact, I'm often hindered by some other defaults, like bad color choice (dark blue on my black terminal) that makes things hard to read. I dont have much vim customization because I can not rely on it always being there. I use a pretty basic setup that lets me be productive in just about any default unix/Linux environment. I find IDEs to have a lot of visual distractions. When I was first exposed to unix in the early 90s, programming using it just clicked for me and I've never really felt hindered by the defaults. I read man pages and the languages' stdlib docs (usually web pages) so I'm a little more than passingly familiar with what's in them and their capabilities and how to navigate them.
This is my mindset as well. I often need to work with text that isn't code. Maybe it's a SQL dump someone sent me, some bespoke configuration format, a collection of log files, etc. Knowing how to manipulate and navigate text is extremely helpful as a general skill. IDEs degrade to notepad.exe quality when presented with unknown formats.
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.
Thank you. I feel like I’m taking crazy pills because I (mostly) hate autocomplete; it mostly just gets in my way. I do almost everything in Sublime Text with very few plug-ins. At the same time everyone around me is using the latest VS Code and going on and on about how great it is when you just hit tab and it writes the code for you. It makes me feel like I’m wrong in some way.
I did it this way for about 20 years and recently moved to VSCode with its integrated terminal. It makes me feel pretty lazy and like I’m “cheating”, but there are some productivity benefits (LSP), and I’m less of a purist than I used to be. I maintained a blog about vim for 3-4 years, so I was pretty committed to that workflow back in the day.
I know about VSCode's terminal, and the few times I've used it seems like an afterthought, bolted on, to the primary function of the program as an editor and file navigator. I don't live in the editor. I live in the shell. The editor is a sub function of living in the shell.
I actually think the VSC terminal is one of the few saving graces it has. Maybe not so much on *nix. It works well enough on Mac, but it really shines on Windows where you’ll have a much easier time running powershell, GitShell and WSL terminals within VSC than outside of it. It also has really good integration with the various Azure CLI tools.
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.
3 replies →
I have an alias for `vim -p $(git grep -li "$1") +"/$1"` that allows me to quickly open files that contain a given string.
I used something similar for a long time, but the past few years I've been using Path Picker.
And with Zsh suffixes you can even drop the pipe.
https://github.com/facebook/PathPicker
> I find cli tools like find/fd/grep/rg are useful because I rarely need to find only the definition of a function, but rather other call sites too, to find out how it is being used
And find/grep are very bad and limited tools for this compared to what an IDE will give you
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.
> 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-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.
9 replies →
Good point re: using error messages. If I call a function incorrectly, the call stack will helpfully point out the file and line number of the location the error was thrown from, just a few keystrokes in vim will get you there.
> the call stack will helpfully point out the file and line number of the location the error was thrown from, just a few keystrokes in vim will get you there.
Or Cmd+Click/Ctrl+Click in an IDE
Uhhh that would involve a mouse, gross ; )
7 replies →
Remarkable. With an ide you just press the hot key for next error and bam, it takes you to the exact line. (No you don’t need a mouse for this.)
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.
> The shell is my development environment
*Hell
Visual distraction in IDEs is amazing. I see my co-workers using Visual Studio or something, and I can't even identify the code they're working on among the mess of the screen. There's so much going on. The clean and pure display in vim in my terminal let's me just focus and get shit done. I honestly don't understand how they get anything done, but to each their own.