| HN Mirror

Oh, wow, those both are good ways to get me wound up :-) I'll do my best to avoid making this into an essay, and also try and avoid the burnout from having this exact conversation over and over and over and over and over and over and over and over in my career

For the first one (which actually is very closely related to the second one), PyCharm understands the files are python, and not text. That enables a few things: jump-to-declaration doesn't use pattern matching, which is fantastic in a codebase that has a bunch of methods named "to_json" or whatever. Find usages isn't "git grep and-good-luck". And, highest of all: PyCharm (and the JetBrains family of editors) have an indescribably good system of inspections and intentions. It's like having an angel on your shoulder spotting things it can prove are wrong. Similar to the sibling comment, people often "but flake8!11" and yeah, better than nothing, but offline inspection systems are nowhere near what I'm talking about. Then, the intention system ties closely into the refactoring system: extract variable finds the other 3 copy-pasta usages and extracts _those_ to a variable, too. Vim, and similar text editors do not have the context enough to know which ones are in scope enough to pull upward and be replaced

I know everyone and their cousin believes their code workflow is awesome, and good for them, so long as I don't have to work with their code or wait the 15 minutes while they manually enact a change that PyCharm would do instantly and correctly. So don't "at" me :-)

For the second, yes, I also deeply regret that JetBrains haven't spent as much time optimizing their IDEs as I would like. But for the aforementioned reasons, I get something for the frustration I endure waiting for that indexing stupidity to finish, or when it eats so much RAM I have to restart it.

And, as I hinted at: I strongly, strongly recommend to colleagues that they don't try to use IdeaVIM because of what I just tried to lay out: text is not code, and thus the primitives that one would use to describe operations done to text are at the wrong level of abstraction for things done to code

    def example():
        jimbo.doit(a, (alpha, beta, charlie))
        timmy.yup(b, (
            #<CURSOR>#
            alpha, beta, charlie
            ))

With ones cursor at the designated spot, pressing "expand selection" (alt-up in the macOS keyboard layout, command-w in the cross-platform one) 4 times will place the selection around that tuple, then command-shift-v will extract both of those tuple usages (after prompting, of course) to a variable awaiting its new name. command-z will undo that _one operation_ and undo the 3 changes to the text file because they were _one operation_. I believe those who say "but I'm a vim ninja, and I can do that same thing" but the amount of mental energy expended to calculate the sequence could be spent thinking about the problem and not the text.

I had almost this same discussion verbatim in the thread about SemGrep with folks because the _source_ is not _the AST_

Hmm, I didn't do a good job about avoiding the essay, and I could keep going literally the rest of the week on this topic, but hopefully that gives insight into the Sisyphusian task I have faced at almost every job my whole career