“It’s really great to see Sun embracing modern scripting languages. There is definitely a need for smarter IDE integration.” – Ryan Paul, Ars Technica
For those of you that missed the news, Sun’s Ted Leung recently announced that an upcoming version of NetBeans would be supporting the Python language. As he put it, “Netbeans has really nice support for Ruby and Javascript, so why should Python be left out?” Indeed. Python support, after all, makes DJango developers and Google App Engine users both a targetable audience for the platform. Which is good.
The trend to add dynamic language support to IDEs is, of course, nothing new. Nor unique to NetBeans; here‘s a piece written in January of ’06 about using Ruby within Eclipse. Virtually every major IDE of consequence, from Eclipse to Microsoft to NetBeans has understood for years now that dynamic languages are not the first choice, but the only choice for large swaths of their target audience. The days of single language IDEs are likely, for all intents and purposes, over.
Nor is that realization a one sided conclusion unique to the IDE projects; language developers and advocates alike have been, for their part, hastening to take advantage of both the technology that the IDEs have assembled and the audiences that consume it. Witness Zend’s efforts to bring PHP to the Eclipse community via the PDT project.
Because it’s logical for both platforms and languages, then, there can be one outcome: IDEs IDEs will be only more capable platforms for dynamic language development going forward. To conclude otherwise would be to ignore both recent history and the behaviors driving same.
But just because the IDEs add functionality doesn’t mean developers will choose to use it.
While I’m not sure if it’s still true, as it once was, that the entire Rails committer team is using TextMate – a text editor – the lesson stands: many dynamic language developers prefer the simplicity of a text editor. One might conclude from this that it’s been an absence of choice: the IDEs, after all, have only added dynamic language support over the past few years. And it’s certainly possible that that is more than a mere contributing factor to the relative unpopularity of IDEs with dynamic language development communities.
But the availability of IDEs supporting dynamic language development is not a new phenomenon. Tools such as ActiveState’s Komodo IDE have been available to interested parties for some years now. The fact is that IDEs are likely to be intrinsically less compelling to dynamic language developers. It’s not that they’re not necessary, nor that they don’t or cannot improve on the development experience. It’s more that as PHP, Python and Ruby are simpler to develop in than, say, Java, the drivers for IDE usage are fewer.
That said, dynamic language IDEs have found both fans and markets.
It’s the size of those markets, in relative terms, that I’m interested in. The overwhelming majority of dynamic language developers I speak with do not use IDEs. The reasons are varied: some are wedded to a particular text editor, others don’t wish to make the functionality for weight/complexity trade-off, and still others have adapted their own workflow such that an IDE adds little. Many of the above have trialed at one time or another the available dynamic language IDEs, only to return to their text editor of choice.
Again, the decision to make traditional IDEs more language heterogeneous generally and more dynamic language friendly specifically is not in question: it will be table stakes soon, assuming that it’s not already. But I do wonder how much success IDEs will have in markets currently dominated by text editors, and what the metrics for success will look like for IDE advocates and purveyors.
Disclaimer: Eclipse, Microsoft, Sun and Zend are RedMonk customers, while ActiveState (Komodo) and MacroMates (TextMate) are not.
