The Atomist way: The perks of editors
Rod Johnson, CEO of Atomist and creator of Spring Framework, sheds some light on what works in code generation and what doesn’t in a recent Medium post (first of a series of blogs). He presents the perks of editors and how they are able to parse and understand projects and make it easy to work with that understanding.
Rod Johnson, the CEO of Atomist and the creator of Spring Framework, recently revealed in a Medium post that Atomist has been working on a new approach as opposed to traditional code generators, which offer “a one way trip: they create a project, allowing basic parameterization (such as project name, base package name or dependencies) and then their contribution ends.”
The problem with the traditional code generators approach is that editing and customizing templates is difficult since one may have to modify generator and template code. One cannot use normal tooling on templates or easily verify that a change to a template hasn’t broken anything — this is the difference between a project and a template, Johnson says.
It’s possible, and much better, to enable the creation and evolution of projects in a way that’s independent of a particular platform, and independent of the origin of the project.
A different approach: Editors
According to the CEO of Atomist, a project template is nothing more than a working project, which means that any project can be used as a template. Another key concept in their approach is that editing is scriptable and composable, to maximize reuse. Plus, a consistent approach can be used to edit different kinds of projects and content.
Johnson claims that “a change made by an editor is indistinguishable from a change made by a developer” but emphasizes that the goal is to make developers more powerful (not to minimize their roles!) “by scaling them up via a polite, invited, automated helper that follows their preferences.”
Another perk is that editors can act on projects that were not created by Atomist, or have been modified by hand. There is no lock-in and projects remain non-magical at all points. Furthermore, they should be able to run anywhere.
How can editors understand projects?
Johnson explains that the above-mentioned goals “must be able to parse and understand projects (both at a language and platform level), and make it easy to work with that understanding. This enables code like the following, which adds Netflix Hystrix support to a Spring Boot project using the appropriate Spring Boot ‘starter‘:”
This is the effect on the Java source tree of running this editor:
As you can see in this example, related operations are combined in one reusable editor. One can operate on a class only if it meets certain criteria.
To show the consistency of approach across languages, Johnson refers to a demo presented by Jessica Kerr on creating and editing Elm projects with Atomist.
This editor needs a “module” parameter, which can be requested from the user via a CLI, web form or the Atomist Slack bot. This approach works across file types.
Johnson also points out that the Elm template/editor “demonstrates more sophisticated possibilities, using the ability to make wide-ranging modifications to an existing project to achieve a single goal, such as evolving a beginner program in accordance with the Elm Architecture.” What this all means is the following: “knowledge can be embodied in and transferred via generators and editors.”
In his next posts, the CEO of Atomist will dive deeper into the syntax of their editor DSL.