Is your IDE tilting at the dynamic language windmill?

Quite a few programmers love having powerful IDEs. These IDEs perform certain simple refactorings somewhat automatically, they can take a compiled language and make it seem a little more like an interpreted language, they can find certain types of errors as you type…

In short, they do a lot of drudge work on the programmer’s behalf. What’s not to like about this? Nothing. These are useful tools. I have been working with Eclipse lately when editing Java, although I really don’t care one way or another. I like what it does but I’m fundamentally indifferent to its existence.

Of course, there are more than a few people who espouse the idea that the most powerful features of these IDEs are only possible with statically typed languages. And that this productivity is so important that it—ummm—eclipses all other considerations such as which language allows you to express a program with the least redundancy.

How interesting.

Do all powerful IDEs require static typing?

The idea that IDEs make you more productive is nothing particularly specific to statically typed languages. Have you ever heard of an editor called Emacs? Did you know that some of the hairiest, most dynamic, self-modifying code ever written was once part of Emacs? And that the author of that dynamic, self-modifying code, some fellow named Jim, went on to develop a popular statically typed language?

Anyways, lots of people use Emacs for Lisp (don’t you love the symmetry? you need to use Lisp for Emacs). They invest a lot of time making themselves more productive.

So here’s what I see from my chair: There’s this group of star-bellied sneetches who say “the important thing about being a productive programmer is having a tool that makes you productive.” And there’s this group of sneetches who say the same dammned thing. The only difference between them is that the star-bellied sneetches say that the productivity of the tool is all about the special things the tool can do when the programs are written in statically typed languages. The plain sneetches love the tool that they can customize so heavily it feels like a personal extension of their mind.

Hmmm.

Who deserves a title bout?

The thing that strikes me as obvious is that I’m the wrong person to argue with a star-bellied sneetch. I use a fairly nice text editor, TextMate, but it doesn’t do 1% of what Emacs does and while it does a lot more than I ever figured out how to make Eclipse do, it also doesn’t even try to do a lot of the star-bellied stuff like move methods around.

The right thing to do is to get two people who both agree that productivity from IDEs is important to debate how to do it. That way there’s one, clear point of debate: does an IDE + static typing beat a programmable editor by an order of magnitude?

Debating with me is going to be entertaining but inconclusive, because we’ll be mixing several arguments up: are IDEs important, and if they are, what’s the best way to make an IDE powerful, and if that is the best way, is it so good that it outweighs other considerations for choosing a programming language? If you stop by my house, that’s a conversation that is going to put a serious dent in my collection of single malts.

The third perspective

I’m not a sneetch in this matter. I spend far, far more time thinking about code than I do editing code. Therefore, I invest more energy looking for ways to improve the way I think about code than I do looking for ways to improve the way I edit code.

Kinda something not entirely unlike what happens when you sit down to improve the performance of a program. First you profile. Then you choose what to optimize. I’ve profiled myself, and what I need is more help deciding what to do than I do doing it.

I am also holding on to a somewhat axiomatic (and irrepressibly optimistic) belief that some languages have orders of magnitude higher signal-to-noise ratio than others. This is important for understanding why I am reluctant to pick a language because my IDE likes it.

For starters, one needs to understand the goal of all this refactoring: it’s to have better code. Better languages also achieve this goal. let’s look at a simple example and work backwards from that to the importance of languages.

Delegation and dynamic programming

Delegation in Ruby is easy because you have send and you have method_missing, so even if you don’t feel like using the built-in SimpleDelegator or Forwardable, you can forward messages whenever and however you like.

Whereas in Java, you need to define an Interface, then make sure that person_doing_the_actual_work implements the interface, then you can use a DynamicProxy to implement delegation. Note that you can’t delegate to a built-in class unless it implements an interface, so you can delegate to ArrayList (because it implements the List interface), but you can’t delegate to String.

(Well, you can forward calls to classes that don't implement interfaces, but you can't make the delegator look like a delegatee. So what you really have is a kind of private inheritence. You cannot, for example, decorate a StringBuffer so that you can set a flag for whether it has been encoded for display in HTML or not, and decorate the append method so that you can throw an exception when an unencoded String is appended to an encoded StringBuffer).

Why can’t you just generate the delegation using the IDE’s handy-dandy feature?

The problem is that code generation produces a static change. It’s a one-time thing, like one of those push-button programming wizards from MSFT. If you change interfaces, perhaps you are refactoring something else, your delegation breaks. So you have to write something relatively dynamic.

In Ruby, it looks things up at run time. I’ll settle for something that can reflect at compile time. But either way, you can’t just do it once. You have to have dynamic code handle the forwarding.

(There are exactly similar problems in all sorts of code. If you write some serialization code by hand or with an IDE, you have a problem when you expand an object. The old code doesn’t know how to serialize the new members. You have to make sure your serialization code reflects on the object so it can keep up with all changes.)

I find that IDEs are nice, but even the most sophisticated IDEs are… static. They make one-time changes to code. I’m far more interested in languages that let me write code that writes code, in languages that let me write code that doesn't need a lot of rewriting and fixing across the board when I make a change. (This is just my perspective. I’m still learning a lot about the intersection between theory and practice in programming languages.)

But this is why you’re tilting at windmills when you ask me why I don’t eschew Ruby for Java just so I can “rename class.”  ¶ 1:18 PM