On Building Things

Building a thing means that there's a thing. Building a tool to build things means that there can be many things, and many people can build their own things.

This is an essay about software things, but could just as easily be about physical things or artistic things.

Building a thing can be a wonderfully rewarding experience, and results in a tangible thing of beauty. One might think that this is enough to be satisfying, but I would like to make a case for building tools to build things. Tools are often underrated, but a tool should be judged not only on its own innate beauty but on the capabilities it gives to others.

In my opinion, a prime example of a beautiful tool in the domain of computer programming is a compiler. This tool is the tool which allows the building of other tools; it is the meta-tool.

There are many different compilers (and interpreters, which are almost the same thing) of varying degrees of beauty - in the eye of the beholder, of course. But the fundamental function of them all is to allow other things or tools to be built much more easily.

Tools aren't only things like scaffolding or compilers; they can be documentation, tutorials. Anything that makes it easier to make things.

Tools can also be hugely empowering. Fundamentally, something like Markdown is "just" text processing, but it empowers people who might otherwise be put off by raw HTML to make great websites. Fundamentally, spreadsheets are "just" unusual ways to write semi-numerical computer programs, but they empower everyone to do quite sophisticated maths which would be time-consuming and error-prone to do by hand. Of course, anyone could learn to write raw HTML or a computer program, but having a good tool allows us to do it quicker, and with less up-front effort.

Alan Kay makes an analogy between physical architecture and software architecture, comparing the state of the art in the latter to pre-classical building:

If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.

We're able to stack some basic blocks together, often in quite elegant ways, but we're missing the knowledge and experience to build taller and span wider. He talks about the revolution of the arch; a self-supporting, stable way of spanning large gaps, but one that can't be built directly. An arch requires scaffolding, which we could think of as "a building to build buildings" - scaffolding is a tool.

Scaffolding in computing can be Domain-Specific Languages (DSL), as used in the Nile/Gezria system, which allow code to be focussed on describing the solution and elide extra complexity while at the same time building-in concepts important to the solution. The code in that language needs to be translated, but this can also be done with a DSL. All of which allows the whole graphics system to be expressed in 593 lines of code plus 966 lines of compiler, rather than the 168,000 (approx) lines in Cairo.

Building a thing is great; it's awesome to make something. A thing is single-use, however, even if it does whatever it does superbly. The next time someone wants a similar thing, they might find it's easier to build another thing rather than adapt the original thing.

If you're looking to build something, please consider that other people might also want to make similar things, and consider making a tool so that everyone can build things more easily.


Comments loading...