I think if you write good code the case for needing advanced re-factoring tools is minimal. If you're writing the same thing time and time again, that should ring alarm bells.

FWIW, for other types of refactorings (I mainly use Java):

  1. Change the name/type of something
  2. Compile
  3. Work through the errors fixing stuff it broke

Maybe that's less efficient than using some IDE tool to do it, but it's not like it takes a long time.

Let's talk again when you're dealing with a codebase with >1000 classes, 5 different programmers of varying ability that you don't have direct control over, a build process that takes 5 minutes to complete as it works its way through a dozen different complex tasks with dependencies on just as many external tools and servers, and you need to do one of these simple "rename" factorings right now because a colleague made a spelling error in a widely used internal method that's about to be promoted to a part of a public API. I guarantee you'll start to question whether change/compile/fix is the right approach to these things...

In that case I'd just write a simple shell script :/

But thank god I don't work on large systems like that.

well, if I was so good to get code right at the first time, I would not need refactoring at all. Alas, I'm not :)

I agree that, all the things you can do with automatic refactoring you can do with a change/compile/fix loop, but it imposes an higher amount of friction, which (even in a subconscious way) pushes you into not making changes.

As a ruby and python dev using vim, I can even feel this in changing a single method name (with sed, obviously not syntax aware), as a java one without a supporting ide I'd seldom venture in a "extract superclass and use it where possible as return value" kind of change.

Sure, maybe I like that friction. If a refactor is going to be a bit of hassle, it makes me think about it more, and evaluate if it really is a good change to make.

That's because many of the people who build those tools have coupled them to an IDE, rather than making a standalone tool that could be made to work with any editor with a little effort. And while it would be changing files without the IDE knowing, version control systems run standalone and modify file currently being edited, too - it's not a problem when you expect it.

A standalone tool can either do static analysis (like a tag index, but more so) or communicate with the language runtime, and just leave the UI to the editor/IDE. Either way, it doesn't need to be in sed & awk.