Summary
Developers who have relied heavily on refactoring support available for static languages are suspicious of the productivity gains promised by dynamic languages.

Advertisement

I have long help a view similar to Ken's post that refactoring support is integral to my productivity. I admit it - I am a refactoring addict! Still, the winds of change are howling and I try to keep abreast of developments in dynamic languages.

A quick search has revealed that Aptana Studio in its Ruby mode has added many of the common refactorings a Java programmer would expect. After installing Aptana and giving it a spin, I don't think that today these features are finished, but when they are done, Ruby will become a much more competitive language for folks addicted to good refactoring support in the IDE. Another interesting development is Duby, written by one of the principals on the JRuby team. It is an attempt to build a language that has Ruby syntax, but provides type inference ala Scala. The main driver for Duby appears to be performance, but surely refactoring support will easier to implement as well.

Smalltalk was the original breeding ground for all of the refactoring movement, including automated refactoring tools (see the original Refactoring Browser).

And there are very few languages that are more dynamic (or less static, as you prefer) than smalltalk.

Of course automated refactorings are, in a way, "less safe" and less bulletproof on smalltalk than in a language providing more static analysis support (thus more static information), but on the other hand the most interesting refactorings are not automated anyway, and if you only use push-button refactoring then you're not a refactoring addict, merely a push-button addict, and TDD (which also comes from the smalltalk community) makes errors due to refactoring much less likely.

Most of the time, when I hear people talking about dynamically typed languages being ill-suited for refactoring, they're people who don't want to think about what refactoring implies, don't want to understand how it came to be (e.g. read Refactoring) and in general purely rely on their tools and hope things will work out in the end.

I know others with the same affliction. I see the point of refactoring (I even do it from time to time, really) but when people do things like "stew over method names", I'm wondering when does refactoring turn from useful activity to a way to get paid while procrastinating. Is it really that big a deal in these cases? I love stew, but how many times can you change the method 'MakeThingGreen' to 'TurnThingGreen' and back again before you look at it and say 'Wow, what a waste a time!'.

> > I love stew, but how many> > times can you change the method 'MakeThingGreen' to> > 'TurnThingGreen' and back again before you look at it> and> > say 'Wow, what a waste a time!'. > > Silly. The correct refactoring is> thing.turnGreen().

But I thought it was

thing.makeGreen()

And my partner thought it should be

thing.makeSurfaceAShimmeryGreenWithBlueTint()

after porting the code to use OpenGL and some fancy lighting.

This is why I'm no good at programming. Forget algorithms and Big O and concurrency and all that crap. I can't name stuff.

> Smalltalk was the original breeding ground for all of the> refactoring movement, including automated refactoring> tools (see the original Refactoring Browser).> > And there are very few languages that are more dynamic (or> less static, as you prefer) than smalltalk.

I have all the respect for Smalltalk as the primordial soup from which all goodness came.

> > Of course automated refactorings are, in a way, "less> safe" and less bulletproof on smalltalk than in a language> providing more static analysis support (thus more static> information), but on the other hand the most interesting> refactorings are not automated anyway, and if you> only use push-button refactoring then you're not a> refactoring addict, merely a push-button addict, and TDD> (which also comes from the smalltalk community) makes> errors due to refactoring much less likely.

Very good point! I am an automated refactoring addict. Refactoring in the large is a matter of discipline and pride in your work.

> > Most of the time, when I hear people talking about> dynamically typed languages being ill-suited for> refactoring, they're people who don't want to think about> what refactoring implies, don't want to understand how it> came to be (e.g. read Refactoring) and in general purely> rely on their tools and hope things will work out in the> end.

I did not say anything about dynamic languages being ill suited. I did say that, for Ruby, I did not find a suitable tool yet. Aptana seems to be on a very ambitious path for their refactoring support and I wish them all the luck. At the same time, I am intrigued by both Scala and Duby as the middle ground between static typing and an expressive language.

> > I admit it - I am a refactoring addict! > > I know others with the same affliction. I see the point of> refactoring (I even do it from time to time, really) but> when people do things like "stew over method names", I'm> wondering when does refactoring turn from useful activity> to a way to get paid while procrastinating. Is it really> that big a deal in these cases? I love stew, but how many> times can you change the method 'MakeThingGreen' to> 'TurnThingGreen' and back again before you look at it and> say 'Wow, what a waste a time!'. > > I only wish that example were entirely contrived :-(

I think you missed the point or I did not express myself clearly. If you have IDE support for "rename method" there is no need to stew. As you come up with a better name, you can confidently rename the method even if its used in 1000 files.

> I think you missed the point or I did not express myself> clearly. If you have IDE support for "rename method" there> is no need to stew. As you come up with a better name, you> can confidently rename the method even if its used in 1000> files.

No, I didn't miss the point. I read the article you linked to and took 'stew about method names' to mean that one thought long and hard about renaming methods. The article then goes on to mention some names being not quite right.

I have seen people agonize hours or, in really extreme cases, days about method names that were not quite right. And the name change was, at best, trivial. So the 'rename' method gets used about 65 times over the course of a day or so for no real net gain.

Those are the sorts of people that I see as really 'addicted to refactoring'. You were probably using the phrase in a euphemistic manner. Which is fine. I just know a few people for which this is a real problem. They often suffer from paralysis by analysis in many situations. This is just one more manifestation of that.

> I think you missed the point or I did not express myself> clearly. If you have IDE support for "rename method" there> is no need to stew. As you come up with a better name, you> can confidently rename the method even if its used in 1000> files.

... assuming, of course, that those 1000 files aren't config files, and don't include some sort of weird loading that the IDE didn't notice, and that the name wasn't exported outside your module, and that it isn't in use in some other developer's workspace in code that isn't checked in, and ...

I personally LOVE refactoring. It's a major tool for keeping my codebases clean. But - IDE refactoring only help me a trifle. Dynamic languages tend to let me do refactoring that abstract away more complexity, because there is usually less mandated boilerplate, and there is more flexibility in how I map the problem to the solution. The lack of boilerplate means that my actual changes are less obscured by noise in the diff, so it is often easier to do refactoring in them - even without the support tools.

> I have seen people agonize hours or, in really extreme> cases, days about method names that were not quite right.> And the name change was, at best, trivial. So the 'rename'> method gets used about 65 times over the course of a day> or so for no real net gain.

And yet, if the naming scheme is not consistent, or if method names are in any way ambiguous or misleading, you force each maintenance programmer to spend weeks reading masses of code in detail to grok the code's purpose and design -- knowledge that might have been obvious with a more consistent naming convention and less ambiguous names.

> > I have seen people agonize hours or, in really extreme> > cases, days about method names that were not quite> right.> > And the name change was, at best, trivial. So the> 'rename'> > method gets used about 65 times over the course of a> day> > or so for no real net gain.> > And yet, if the naming scheme is not consistent, or if> method names are in any way ambiguous or misleading, you> force each maintenance programmer to spend weeks reading> masses of code in detail to grok the code's purpose and> design -- knowledge that might have been obvious with a> more consistent naming convention and less ambiguous names.

Having done (still doing, actually) my share of maintenance, I can safely say that any code base that took me weeks to grok was not due to horribly ambiguous names. Bad pointers, poorly documented side effects, methods doing too many things and stuff like that are usually the cause of my maintenance angst. I've never run into a project where things were so horribly named as to cause a major delay in grokking the code base. And I've seen some horribly named things.

I am not sure what is possible, but I would be willing to restrict myself to a subset of Ruby if it helped with type inference and by extension refactoring support. I am not looking for a general solution - well-defined boundaries will suffice. Again, the work on Duby is very encouraging to me.

> > Ruby, and other current dynamically typed languages, don't> have this luxury, so I'm curious to see how Aptana> resolves the problem I gave here:> > http://beust.com/weblog/archives/000414.html> > Do you know?> > -- > Cedric