“There is already a command line for it, why can’t my favorite editor support this language?” As a developer, you’re probably familiar with this sentiment, and in reality there has never been a better time to be a software developer.
Developers have access to a growing list of languages, frameworks, libraries, and technologies that can help them solve the problems they are tasked to tackle. However, the abundance of choices often hinders the ability of Integrated Development Environments (IDEs) and code editors to support such an abundance of choice. As a result, developers often choose to use multiple IDEs and editors for building their solutions, in order to get access to best IDE support.
IDEs are frequently architected to have direct access to the tools related to the technology for which they were designed — for programming languages this often means that IDE has access to parsers, compilers and an in memory presentation of the developed code usually in the form of an Abstract Syntax Tree (AST). This approach also means that IDE developers need to create and maintain these tools.
As an example, Eclipse Java Development Tools (JDT) project provides a compiler for Java and a Java editor which in turn uses the AST generated to implement features like code assist, outlines, refactoring, etc.
Another approach is to define an API that the IDE will invoke to provide language features. In this architecture, the IDE has no real knowledge of the programming language and instead relies on the implementations of the interface.
We think this approach has a couple of advantages: first, it allows the interfaces to be implemented by the communities that create the technology, and so know it best; second, it frees up IDE developers for what they know best — we think this results in better IDEs and editors.
Unfortunately, we do not get the full benefits of the approach because there are as many of such interfaces defined as there are editors and IDEs.
Continue reading “A common interface for building developer tools”
