IDE’s and Dynamic Languages

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.


14 Responses to “IDE’s and Dynamic Languages”

  1. marxy says:

    The benefits of dynamic languages, such as being able to re-factor the type of object being passed around without changing all the declarations of methods that take that object, run counter to the ability of an IDE to do intelligent things like show code completion accurately while writing rather than running your code.

    This is a tough problem.

    I use Komodo and it does a remarkable job considering this problem.

    Personally, I think the solution lies in having a dynamic language that lets you give hints about the types, perhaps as decorators, that might be used by an IDE.

    If you want to pour out code, a simple editor, with some code colouring and bracket balancing smarkts is terrific.

    I switch between the two depending on my mood.

  2. Michael Hudson says:

    5-10 years? Heck, even Python is 17 years old now, Ruby 12, … 30 is about right for Smalltalk, but Lisp is more like 50 🙂

  3. Seo Sanghyeon says:

    vi and emacs are extensible, so why “willingly give up their text editors with IDE features”? Why not have those features as an extension of vi and emacs?

    In other words, why wouldn’t one prefer Bicycle Repair Man, if it improved enough?

  4. keith says:

    Thank you, thank you. An excellent summary of a situation that I find deeply vexing. It boggles my mind to have folks claim that, for instance, there’s just no way to have good support for refactoring tools in a dynamic language. When one points out that what we now think of as refactoring tools came from Smalltalk they just get this blank look on their faces.

    Personally, I find it very weird that people can be fans of dynamic languages, with all that this implies about rich, flexible, explorable _runtime_ behavior and yet still think of their programs as lumps of text sitting in files.

  5. Adrian Kuhn says:

    One of the best IDE’s of dynamic languages is Hermion, a recent extensions of Squeak’s normal IDE. It traces your running program/tests and feeds back traced type information into the code editor. Type information is used for better auto-completion and even available as in-test drop-down menues (like the ones in MS Office). Really worth checking out, I am addicted.

  6. yml says:

    Komodo Edit is hitting the suit spot for me even. I would be very happy if all the features you have describe are added.

  7. Funny, I actually wrote about IDEs being useful for dynamic language developers in April. I am one of those Python developers that likes good tools, and IDE is a nice way to tie them together.

    Probably the main thing I look in an IDE is the debugger support. I was really spoiled with the debugger in the Microsoft Visual C++. I can work with gdb and pdb (and in fact do for quick little checks), but I just find that I work faster with a visual debugger that let’s me see everything at a glance and it also makes it easy to drill down into directions I wasn’t anticipating when I started debugging.

    When I switched from C++ to Python, one of the main annoyances I had was that there was no compile step to catch my typing mistakes. Instead, I had to launch the application which in case of Chandler took a long time, use it to get to the piece of code that exercised my code, and if I hit a typo it was aggravating. Good, fast tests help of course, but this is an area I think IDEs can also shine. When I found Pydev, and its integration with Pylint, things suddenly became enjoyable: the IDE is pointing out my errors as I type!

    I take syntax highlighting for granted, but I have never really used refactoring tools so that is an area of functionality that I don’t miss much.

  8. “But I do wonder how much success IDEs will have in markets currently dominated by text editors”

    You might want to ask Wingware. Their WingIDE for Python seems to be doing pretty well.

  9. Mitch says:

    A perplexing problem trying to find a real IDE for dynamic languages. So much so, I wrote a version 0.1 for (Iron)Python on the .NET framework at:

    What success would look like to me is being able to launch an IDE in a web browser, from any location, and point it to whatever project I happen to be working on, which is usually a web-based project. It seems so… what, I don’t know… that we do not have any real web-based IDE’s for developing, you know, web applications. It seems our paradigm is oh so wrong.

  10. I think most modern IDE features are just bells and whistles just put there to give something new each year. Lets be serious most developers, regardless of the language they are using, do not use the majority of the features their IDE of choice gives them. Syntax checking, syntax coloring, auto complete, auto documentation generation and maybe GUI building are the most we use these days.

  11. […] Zitate zum Thema dynamisch getypte Sprachen fand ich zuletzt in Ted Leung’s Post “IDE’s and Dynamic Languages“, der sich auf jeden Fall zur vollständigen Lektüre eignet – auch die […]

  12. […] IDE’s and Dynamic Languages. Ted Leung’s got some useful and insightful things to say about dynamic languages, history, IDEs and the people who use them. While I still think many of the features in a modern IDE are crutches, I hope that what Ted is alluding to becomes a reality. […]

  13. […] IDE’s and Dynamic Languages at Ted Leung on the Air […]

Leave a Reply