Resident IDEvil

by chromatic

Hearing that Uncle Bob feels afraid to refactor Ruby code without an IDE sends me back to the stern-but-loving embrace of Vim, my comprehensive test coverage, and a decent version control system.

Yikes. That's like forgetting how to type. (No, that's not a Hindley-Milner joke.)


8 Comments

Robert
2007-08-17 15:24:12
Except for the really major stuff I do in Java...Vim is my friend for everything!
cariaso
2007-08-17 16:12:08
I briefly dabbled in java under eclipse. These days its back to python and emacs. I will confess that my test coverage is poor. I don't miss Java, but I do miss the ease of highlight/right-click/refactor eclipse offered me.


Yes I can do the reactorings by hand, but as Fowler's Refactoring teaches, and the IDEs prove -- refactoring can be automated. If it can be automated, it probably should be.


While looking at code from a high level I may recognize the benefits of a rename, extract-subroutine, or pull up. Doing that refactoring requires mentally zooming into a new frame of reference. Mentally that is a costly and unnecessary context switch.


Anybody gotten BicycleRepairMan working under windows/idle or cygwin/emacs?

Adrian Howard
2007-08-20 09:03:00
How about if you had to jump back to something without global search/replace? Would you feel more nervous about making changes and maybe missing something?


That's what it's like. You go from a mechanised process that _always_ works - you can move forward with 100% confidence - to one where you have to do a whole lot of manual work that you can get wrong. It sure as hell does slow you down.


As I said in an old perlmonks post


"In Perl if I want to extract a method I have to select the code I want as a separate method. Wrap in in sub {}. Figure out what local vars it needs and pass them as arguments. Figure out what local vars it creates/changes and are used by the rest of the method and return them as results. Add the call to the new method into the old code. Spend a second or two looking at it to make sure I've not missed anything. Re-run the tests just to be sure.


If I'm writing Java in IntelliJ all I do is select the code I want as a separate method, hit Ctrl-Alt-M, type in the new method name and hit return.


It takes longer to describe that it does to do. The IDE does all the tedious make-work for me and it always works so I don't have to spend brain power catching my own typos or running tests to make sure that I didn't break anything."


Of course, in my opinion, it doesn't slow you down as much as Ruby (or Perl... or Lisp :-) speeds you up. But it's still a pain.


I too wish for decent refactoring tools in dynamic languages.

chromatic
2007-08-20 21:06:18
@Adrian, oh I certainly do wish for refactoring tools for any of the languages I program in these days... but given the choice of using the tools while losing the desire or ability to refactor by hand if necessary, I'll go without!
Adrian Howard
2007-08-21 06:16:45
Fair enough!


Although I once encountered somebody using a similar argument for staying with a line-editor instead of one of those fancy-pants "visual" editors :-)

Daniel Berger
2007-08-24 06:21:57
Interesting that it only seems to be the pointy-clicky Java (or ex-Java) programmers who obsess over IDE's and refactoring.
chromatic
2007-08-24 09:26:09
@Daniel, that's because Java lacks so many abstraction possibilities that it's almost unusable without an IDE.
Daniel Berger
2007-08-24 10:01:43
@chromatic, On top of that, I think it's also the sort of overall architecture that Java programmers tend to develop. I saw Uncle Bob's talk at RailsConf about refactoring Ruby code. He's a very good speaker, btw. :)


Unfortunately, his idea of refactoring was to take a simple (but deep) class and break it down by creating an excessively (IMO) wide (but shallow) class hierarchy tied to some GoF pattern. With a wider class hierarchy (and thus many more classes) refactoring starts to become more of an issue.


I've seen this sort of thing from other ex-Java programmers, so it's not just Uncle Bob. I think wide-but-shallow class hierarchies are more or less "the Java way".