Just about two weeks ago, Stephen O’Grady was wondering about the market for IDE’s for dynamic languages. His post followed on Sun’s announcement that we’re going to be doing some work on IDE support for Python. Here’s his closing pondering:

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.

Back to the Future

One of the points that I’ve been trying to make since I’ve gotten back in to the languages space is that a lot of what is happening in languages now is unpausing the nuclear winter that Java imposed on the programming language space. If you haven’t been following this space for a while, you’d believe that all this dynamic language stuff was invented in the last 5 or 10 years or so. But it wasn’t. Today when you say dynamic languages, people assume that you are talking about Ruby, Python, Groovy, Javascript, PHP, or Perl, with a number of other languages also entering the mix. The truth is that the intellectual forbears of these languages, Lisp and Smalltalk, were invented about 30 years ago or so. At their height, both of them were running on hardware that was specifically designed to execute programs written in these languages. The ideas for GUI’s which we now take for granted in our modern desktop work environments were pioneered on these systems. These systems included the predecessors of today’s IDE’s. They were written in dynamic languages, for use on dynamic languages. They did not include some of the most maligned features of “modern” IDE’s, such as bloat or wizards that spew out pages of autogenerated boilerplate code. People that actually have used these systems were highly productive on them.

I don’t think that word means what you think it means…

Stephen asserts that he’s talked to lots of dynamic language developers and that they don’t use IDE’s. He cites the Rails committers usage of Textmate as proof that IDE’s are not being used. I guess it depends what an IDE is. Textmate includes automatic syntax verification and code completion, which are not really features that have anything to do with edit text, and both of which require some understanding of what a program means in order to do their job. I’d call those IDE features. The ability to perform semantic manipulations on programs is the essence of what I think an IDE is. Maybe we should just say “good tools” instead of IDE, since a number of people that I’ve talked to seem to think that in order to be an IDE, the tool has to be huge, written in Java, and include feature for generating reams of boiler plate code – none of which fit my criteria for what makes a good programming tool. As best I can tell, Textmate (and other text editors) do not provide features like “find all uses of an identifier” or the ability to refactor ones code. Given the high Test Driven nature of the Ruby community, and to a lesser extent the Python community, I’d be surprised if a tool that could correctly and reliably refactor programs would be uninteresting.

The flight to dynamic languages is a flight away from boilerplate code, a flight to semantically richer control abstractions via mechanism like closures, a flight to appropriate use of metalinguistic programming via meta-level functionality (also known as Doman Specific Languages), and generally a flight to more productivity. If developers are willing to change languages to get more productivity, I believe that sufficiently powerful tools will also be adopted if they can consistently deliver higher degrees of productivity.

Chasm crossing

Stephen talked to existing dynamic language developers. While early adopters are highly valuable audience, they are not the only audience. The lack (or perceived lack, depending on your point of view) of good tools is a barrier to the adoption of dynamic languages. If dynamic languages are to attract a much larger audience, then I think that the development of good tools is an important step towards making that happen. If you think that that tool is named an “IDE”, then we need that.

My experience working at OSAF was that we hired a number of people who were skilled developers but had no previous Python experience. These folks were able to learn the language without any problems, but many of them wanted richer tools. Most of the available tools for Python had problems of one kind or another, including slowness, instability, unreliability and lack of refactoring tools. These were highly skilled people who had worked on and shipped big systems before, who both appreciated the benefits of Python, and the benefits of high quality tools. There are more of these people who are the target audience to jump to using dynamic languages, and I think that having a good tool story for these folks is important.

What is success?

Stephen wants to know what success looks like. Here’s my personal take:

Deliver tools that understand programs at a semantic level and which use that knowledge to reliably refactor dynamic languages using a substantial number of the refactorings in the book “Refactoring: Improving the Design of Existing Code” (Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts). These tools should have outstanding user experiences, including performance and footprint characteristics. People coming from Eclipse/Netbeans/IntelliJ/Visual Studio/XCode should not be wishing for their old tools when using these tools.

Once such tools are actually shipping, there are several possible definitions of success:

In the Java world (not so much the C# world) you have your IDE people, and you have the people using vi and emacs. If the percentage breakdown of IDEs vs text editors for dynamic languages, is the same as that for Java, then that’s success.

Real success would be when lots of people willingly give up their text editors with IDE features for these tools – I was an Emacs guy until Eclipse started refactoring programs.