The Effect of Language Design on ToolingPosted: August 5, 2010
As another reflection on the JVM Language Summit (which was last week), one thing that I noticed both last year and this year is that very few language developers seem to talk much about tooling or integration with existing tools (there was one excellent talk about the Groovy plugin for Eclipse, however). Most of the language discussions get focused on things like syntax/semantics and performance. It’s great that you have some ultra-flexible syntax for your new language and all . . . but does it actually have the ecosystem around it to make it usable in production environments by non-experts? Is there IDE integration? Can I auto-complete, find usages of methods, or refactor things easily? Is there a usable debugger? Can it integrate cleanly with existing libraries written in Java? Is the error reporting reasonable? Are the stack traces readable? Can I profile it? Does it work with existing third-party tools like code coverage tools, or does it require a custom toolkit?
I ask those not to be totally pedantic and annoying, but because they’re important to actual users, and until those questions have reasonable answers the language itself is far less attractive. A language with the cleanest, most powerful syntax in the world isn’t particularly usable if the tools aren’t there.
It seems like the attitude of the language designers is often that those questions are unrelated to the design of the language; designing a great language is one problem, and making sure it has great tools is an entirely orthogonal problem to be solved by someone else at some point down the road. That might be true to a certain degree in a world where every language had infinite development resources at its disposal, but in reality the design of the language has a huge impact on the ability to take advantage of existing tools or to build new ones. If the language is dynamically typed, a good IDE is going to be hard. If it’s a JVM language that’s interpreted at runtime or compiles down to bytecode that doesn’t look much like a standard Java class with normal names and line numbers, standard Java debuggers and profilers won’t understand your code, Java integration will be difficult, and stack traces will be jumbled. Some of those problems can be patched up to some extent by the language itself (like stack traces and Java integration), while others (like needing a custom debugger) require a huge amount of work to overcome.
The thing is, developing that ecosystem of tools is hard and time consuming. Writing a parser and a compiler is a relatively small amount of work relative to the work needed to also create a good IDE, a good debugger, a good profiler, and all those other tools. The work there shouldn’t be trivialized, it shouldn’t be seen as an afterthought, and because the tool-ability of a language is so heavily influenced by the language’s design, it’s something that needs to be taken into account from the very beginning.
But for whatever reason, I don’t think I’ve ever seen that happen. I’ve seen plenty of “announcing my new language” presentations (and read plenty of such blogs), and I don’t think I’ve ever once seen anyone say “we designed it this way so we could re-use the existing Java debugging tools” or “we designed it this way so we could provide a really great IDE experience.” Is it because the people developing the languages don’t really use those tools themselves and so don’t think about them? Is it because people see tool development as a separate problem that should be solved separately from language design? Is there something else going on?
I know someone out there will try to make the argument that good languages don’t need tools beyond Emacs and a REPL and that only blurb languages like Java need tools to make them usable, but I think that’s an argument for another time. That argument can apply to IDEs, but I don’t think it applies to other sorts of tools: no matter how good the language, everyone needs a good debugger, a good profiler, good error reporting, or integration to other libraries from time to time. Those things are all often just as important as the language’s syntax and capabilities when it comes to developer adoption and productivity, so they should be thought of at language design time, rather than after the fact.