The internets are buzzing with new IDE ideas. I credit Bret Victor’s masterful demo for much of this. Chris Granger is having amazing success kickstarting his IDE concept. Josh Marinacci discussed some possibilities. [Another one: Instant C#] I have been working in this area for over a decade and have very mixed feelings about these events. On the one hand, it is great to wake people out of their stupor and and show them what might be possible. But on the other hand I am bothered with the unspoken implication that such things are possible with current programming languages. Just slap a magical new IDE on top of Java or JavaScript and the world will be a better place. Unfortunately I don’t believe that is possible, and I fear it will lead only to disappointment and further fatalism.



Live code execution is an instructive issue. Annotate the code with actual execution values. See the semantics of the code change as you edit it. Eliminate debugging! Cool idea. A cool idea that has been proposed repeatedly for over 30 years. There is a long history of sketchy demos of live code execution that have never progressed past the demo (including my own). The reason is that there are fundamental and intractable problems. What about mutable state? [but see Circa] What about I/O? What about non-determinism and asynchrony? If live code execution only works for factorial functions and the like, it is pretty much irrelevant to real programmers. In general you will still need to edit dead code and use a traditional debugger to examine its execution. So all you have done is complicate the IDE. Why bother?

The same tradeoff kills many proposals for fancy new ways to visualize code. Hundreds of papers have been published about new ways to query and visualize code. They look pretty in cherry-picked examples, but they don’t work for the whole range and scale of real world programs. So why bother with the complexity of limited purpose features? Coming up with new general purpose code visualizations is actually very hard, especially if you are not allowed to change the language to help out.

The fundamental reason IDEs have dead-ended is that they are constrained by the syntax and semantics of our programming languages. Our programming languages were all designed to be used with a text editor. It is therefore not surprising that our IDEs amount to tarted-up text editors. Likewise our programming languages were all designed with an imperative semantics that efficiently matches the hardware but defies static visualization. Indeed it would be a miracle if we could slap a new IDE on top of an old language and magically alter its syntactic and semantic assumptions. I don’t believe in miracles.

Languages and IDEs have co-evolved and neither can change without the other also changing. That is why three years ago I put aside my IDE work to focus on language design. Getting rid of imperative semantics is one of the goals. Another is getting rid of source text files (as well as ASTs, which carry all the baggage of a textual encoding minus the readability). This has turned out to be really really hard. And lonely – no one wants to even talk about these crazy ideas. Nevertheless I firmly believe that so long as we are programming in decendants of assembly language we will continue to program in descendants of text editors.