The Effect of Language Design on Tooling

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.

5 Comments on “The Effect of Language Design on Tooling”

  1. Henry Bowers says:

    This post insightfully and concisely identifies the “last mile” of language design. Any new language initiative that ignores it predestines its offspring to the scrap heap. All you aspiring language designers out there, take heed.

  2. completely agree – tools are terribly important. the reality of professional software development (and i don’t deplore that at all!) is that we don’t write functions to find prime numbers but code that interacts with a myriad of existing libraries. in that context code completion to explore those libraries, refactoring support to improve your code as you learn, and the ability to debug and profile the amalgam of your own code and those libraries are all crucial.

    Scala is a good example: a by-now very mature language with still rudimentary (but steadily improving) IDE support, that plays well with debuggers and profilers because it compiles down to Java byte-code that maximises interoperability with Java-derived byte-code.

  3. Sadly there is still a disconnect between many language designers and their users. From what I’ve seen both Scala and Groovy are difficult to tool sucessfully due to complexities in the language. I believe that Fantom will prove a lot simpler to tool, particularly with its built in type/slot database

    It also appears in those who only code low-level libraries and those who code at the application level (typically integrating data from many sources) often want different things from a language. An enterprise developer is constantly handling null and bad data, whereas a low-level API designer hardly ever sees or designs such things.

  4. Patrick says:

    Since this is a guidewire blog, Guidewire really needs to look at Eclipse/IntelliJ for how to do good tooling. Features I need are:

    1. Make certain directories invisible to the IDE (ie. hide all .svn directories so all these directories and their contents become part of the Studio in memory cache). This allows me to do version control outside of the Studio

    2. Make Studio responsive so I don’t have to hit “Ctrl F” before I switch to another application

    3. Allow resources to be refreshed from their source if they have been edited outside of Studio.

    Other than, the tooling is pretty good.

  5. Jeff Griffith says:

    I had a discussion with my supervisor about things like this and it can be summed up as:

    Real Computer Scientists don’t write code; they design the rules by which code is written.

    My background starts with Electrical Engineering. I chose my first job as a Test Engineer because I was taught that the tools I use shape the product of my labor, so I needed to understand what my tools were doing to shape my thinking (and Test Enigeering is all about what the tools are doing to the test).

    Pure scientists avoid thinking about tools to insure that tools don’t shape the result. The danger is that they design languages that, while very educational, cannot be used (e.g. Occam).

    TDD can be a big help with this problem because it requires that the capabilities of the language be expressed in testable ways. For example, to test type inferencing the test tool has to be able to determine the type of the result. This means that a facility to determine the type of an arbitrary object has to exist and the fact that this facility is used in one place can trigger requests for it in others (avoiding the problem of “I didn’t know enough about your work to ask for it and you didn’t know enough about my work to tell me you had it”).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s