INTERCAL!

Ruby, and Java, are both strongly typed, and there is no problem doing find usages, navigate to definition, and the other basic refactors. As a matter of fact. The only place that a refactor may fail is in the case of passing blocks, closures and continuations.

The reason the tools aren’t there is support. Ruby didn’t have much support until Rails came around. Now Eclipse (via RDT) and NetBeans are making large strides. There is no reason that TextMate shouldn’t have the ability to refactor soon.

Expanding on flexpert’s point: Not only did SmallTalk have excellent code navigation and refactoring support, SmallTalk is where the refactoring support was first conceived.

Sure, one can use “coding and naming conventions” to clarify the design of dynamic code, or “ask the argument to a function about its type”, but this can easily become unmanageable in large teams or long projects.

I have done my share of coding in type-agnostic languages, but in most of these cases, the end result was a quick “one time” script or tool. When I sense that the life of the tool will become relatively long, I typically switch to a “static type” kind of languages.

Sadly AFAIK there is only one decent tool for managing large Ruby projects, and that is TextMate. Downside: it’s only available for Mac. It is probably the one good reason for owning a Mac, if there were no others. I’d love to see a Linux port - but I don’t see that happening (since the developer said they won’t).

Keep up the good work.

Eclipse evolved from VisualAge for Java which had evolved from VisualAge for Smalltalk. Despite the dynamic nature of Smalltalk, VisualAge for Smalltalk (and other Smalltalk environments) include fantastic code navigation, refactoring, etc.

It’s the dynamic nature of Smalltalk that allowed it’s amazing tooling. Ruby shares that nature with Smalltalk. It’s only a matter of time before the tooling is here for Ruby.

That’s untrue. Static checks can catch all bugs. Perhaps not in your language, or with your tools, but they can, thanks to the Curry-Howard isomorphism.

“it’s amazing how easy understanding a massive code base can become”

I expect that programmers in dynamic languages tend to modularise their code more to alleviate these issues.

IDEs fail when you do more interesting things. For example, Java lacks method references, so I’ll make a Runnable:

new Runnable()
{
. . public void run()
. . {
. . . . otherMethod();
. . }
}

Now I can pass that around to anywhere that takes a Runnable, and the IDE’s “who calls this?” feature is useless. You can get more information from a running program plus source code than source code alone.

Interfaces and implementations really are not dynamic typing.

“Got a method with an argument passed in? What is it?”

Ask it.