Kurt Schrader wonders if he's the first person to hit a point in a Rails app where he wonders if he's "finally hit the point where the cost of maintaining our code in Ruby is higher than the savings by writing it in Ruby in the first place?"

He says that:

• He misses the refactoring tools of IDEA, and
• Although it may have taken longer to reach, he feels he's on "the same old curve to all of the standard problems you run into when programming a webapp in any language."

Of course, he's not the first person to see such problems. As I write about in a forthcoming column in SD Times, basically as soon as you start getting into professional-level complexity in Ruby, you start seeing that it's no silver bullet. A great language, yes, but not a silver bullet.

Rails, too, is a very nice framework / DSL, but has huge shortcomings -- contorting it to work with the naming not-quite-conventions of legacy databases is enough to make me consider it a "new projects only" tool.

Of course, refactoring IDEs have not been around for very long and it's undoubtedly the case that people are striving to build refactoring Ruby IDEs. The challenge is making refactorings bullet-proof in a language with a dynamic type system. You can't have a "press the button" refactoring that works 95% of the time. This is a mistake that even today's refactoring IDEs make: the "review these changes" dialog they pop up. They're about as useful as "Are you sure you want to delete that?" in file dialogs. No one actually considers the question, they just hit "OK" and see if it breaks.