I spent part of my weekend absorbing Rod Johnson’s ‘Software That Writes And Evolves Software‘, which introduces what he’s been doing at his new company Atomist, and particularly the concept of ‘Editors’, which are essentially configuration templates for programs. The combination of Atomist and its Editors is a powerful new means of metaprogramming.

I’ll repeat Rod’s suggestion that it’s well worth watching Jessica Kerr’s demo of using Atomist and Editors with Elm:

Why this could be huge

Firstly Rod has form for making the lives of developers easier. His Spring Framework for Java transformed the landscape of Enterprise Java programming, and largely supplanted the ‘Enterprise Edition’ parts of Java Enterprise Edition (JEE [or more commonly J2EE]).

The war against boilerplate

One of the trickier things about using the EE parts of JEE was the sheer volume of boilerplate code needed to get something like Enterprise Java Beans (EJB) working. This is a sickness that still plagues Java to this day – witness Trisha Gee’s Java 8 in Anger (and particularly the parts about Lambdas). Spring fixed this by stripping out the boilerplate and putting the essence into a config file for dependency injection – this got even better when Rod brought Adrian Colyer on board to integrate aspect oriented programming, as it became possible to do really powerful stuff with just a few lines of code.

Jess’s Elm demo shows that the war against boilerplate rumbles on. Even modern programming languages that are supposed to be simple and expressive make developers do grunt work to get things done, so there’s a natural tendency towards scripting away the boring stuff – something that Atomist provides a framework for.

For infrastructure (as code) too…

Atomist’s web site shouts ‘BUILD APPLICATIONS, NOT INFRASTRUCTURE’, but there’s clearly a need for this stuff in the realm of infrastructure as code. Gareth Rushgrove asked yesterday ‘Does anyone have a tool for black box testing AWS AMIs?’ the discussion rapidly descends into ‘everybody starts from scratch’ with a side order of ‘there should be a better way’. The issue here is that for any particular use case it’s easier to hack something together with single use scripts than it might be to learn the framework that does it properly. Metaprogramming is potentially the answer here, but it also raises an important issue…

This stuff is hard

If programming is hard then metaprogramming is hard squared – you need to be able to elevate the thought process to reasoning about reasoning.

Jessica’s demo is impressive, and she makes it look easy, but I take it with the pinch of salt that Jessica is a programming goddess, and she can do stuff with functors that makes my brain melt.

Documentation, samples and examples to the rescue

Perhaps the whole point here isn’t to *do* metaprogramming, but to use metaprogramming. Spring didn’t have to be easy to write, but it was easy to use. Likewise if the hard work is done for us by Rod, and Jessica, and Gareth then that provides a boost for everybody else as we stand on the shoulders of giants.

It’s about making the right way to do things also the easy way to do things – from a learning perspective, and Rod, Jessica and Gareth all have great form here with their books and presentations. If Atomist succeeds then it will be because the documentation, samples and examples that come with it make it easier to get things done with Atomist – the value isn’t just in the tool (or the approach that underlies it), but in the learning ecosystem around the tool.

I have great hopes that metaprogramming (and particularly the Atomist implementation of metaprogramming) will help us win the war against boilerplate (and hacked together scripts) – because it will be easier to start with their documentation, samples and examples.