IDE and Language Religion. Move Along.

Tim Bray thinks you can do refactoring in a dynamic language by getting the necessary data from just running the code. “I’ll bet Tim’s IDE will also be able to tell you when you write an infinite loop!” the programming languages student said snarkily.

Cedric Beust calls him on it. I agree, though I don’t know anything about Groovy. Left out of the discussion is, as always, ML (c’mon, Cornell folks, step up!), which gives you static type guarantees as well as the “convenience” of not specifying types. (At the expense of having to debug type conflicts… always a good time.)

I guess I still have to be a Schemer at heart, and I still have to use JavaScript due to working in the tubes, but I am smitten with Java, for basically one reason: IntelliJ.

Two important features:

• Control-click to go to a method’s definition. Nothing helps me understand the code more than following a method to its definition. And where I work, there’s a lot of code to understand. My heart actually goes out to my co-workers who try to get by with Emacs and vi, who have to scroll up to find what package a symbol comes from, then tab-complete their way through the package hierarchy to get to the file. Only to find out that that’s just an interface.
• Renaming. This is Tim Bray’s desire. AKA “find usages.” I am sick obsessive about my names. They have to be perfect. And as I’m developing a chunk of code, sometimes a method’s purpose changes. When that happens, the name must change. Otherwise, when another engineer looks at it in 5 months, they won’t understand what the code does, and they’ll write a bug because of it.

Maybe I’m just spoiled, but I couldn’t imagine working on a project as large as — in both lines of code, dependencies, and number of engineers — as Blogger without IntelliJ without taking a significant hit in productivity, code quality, and maintainability. The IDE lets me be in control of the code in a way that I never felt before.

Perhaps that’s something you kids and your startups should think about. If your project lasts two years (or seven, though things have been rewritten a few times), in what state will your super-dynamic language code be? Will your new hire be able to figure out what’s going on without significant wading? Will methods and classes be named incorrectly because there was too much friction to set things right?

And seriously: the real magic bullet for programmer productivity? Control-space name completion. Someone tell Fred Brooks.