Text file driven applications

The vast majority of our software applications are driven by graphical user interfaces. There is a certain charm, however, to doing, or driving, things using a text file. I’m not talking about things like computer code, or software configurations being written in text files. I’m talking about using text files to drive an application that most people think should be done, or are used to doing, via point and click, drag and drop visual metaphors.

“Charm” of course, is a very subjective word, and nostalgia and Stockholm syndrome are dangerously closely related. However, if you are a child of the age of LaTeX and the pine (or elm) email client, let me regale you with a short list of fairly new software (and some old ones) that still let you use text files to do a task the young people would associate first with a graphical user interface.

Lets start with some age old ones

LaTeX + picture environment.

Many of us, of a certain age, spent hours getting that drawing just right in the LaTeX picture environment. It was built into LaTeX and produced graphics with a certain retro charm. It got the job done, but was a bit of a horror, to be honest.

I was happy to find that there is a new modern package called TikZ that has taken up the baton


You only ran into this if you were an EE. I used Pspice, which is a commercial implementation of the SPICE concept. This is a circuit simulator. Current students are probably exposed only to the point and click interface, that allows you to drag and drop resistors and transistors and chips onto a canvas and then hook them up by drawing wires, but the original was driven by a text file. Your wrote down all your components and their values in the text file and then created a “net”, a list of all the connections between the elements. Then you ran the simulation.

I swiped this from this presentation.

Now lets do two recent ones:


I fell completely in love with this recently. It’s a text driven CAD tool. A lot of us have used CAD, and CAD is the poster child use case for graphical interfaces. There are many grainy videos of amazing computer demos from the 1960s. Some historical guy is demonstrating this amazing thing they’ve built that pushes the ancient computer technology to it’s limit, and it is almost always about how no one is going to use keyboards any more. They will be using mice, or light pens or haptic gloves. And the poster child application is often a CAD. Look how we can design this rocket by drawing three dimensional cylinders! So it is all the more breathtaking to find a modern CAD application that is text driven.


UML diagrams are the mainstay of stodgy, conservative, software engineering houses. I kid, I kid. But UML diagrams, you say, are drawn using Word (shudder!), or perhaps some specialized UML drawing software. I like to draw them using PlantUML, which even has a VSCode plugin that allows you to preview the UML diagram live.

Updates, after feedback from my colleagues on lobste.rs:


POVray creates photorealistic scene renderings. To have POVray ender a scene, the user describes the scene in a text file using the POVray scene description language and then passes it to POVray to do the rendering.

A POVray plugin for VS Code. Cool. Cool.

Susam Pal has a great series of examples of POVray scripts.


LilyPond enables the user to generate musical scores using textual notation. It is spiritually similar to LaTeX. There is an online editor here where you can play around with creating scores.

There is a VS Code plugin too. But I could not get it to work.


The Graphviz layout programs take descriptions of graphs in a simple text language, and print them as diagrams in different output formats. The simplest format I know of is the dot format.


Mermaid is a bit like PlantUML+. It lets you create UML diagrams and more using text descriptions. Interestingly, gitlab seems to support mermaid out of the box, which means that markdown documents can include mermaid diagrams.

Diagrams taken from the github page.


This is a subset of PlantUML/mermaid. It only generates message sequence charts from it’s scripting language.

Why use such an archaic modality?

I know I talked about charm, but there are some concrete reasons why I prefer the text file driven mode for many things. The primary one is that I can focus on the fundamental content of the diagram or task instead of being distracted by font sizes, or milimeter level adjustments of components. This was true of LaTeX, and it is true of PlantUML. In most cases the tool taking in the text file as input makes some layout decisions automatically. In most cases, this is good enough, and in many cases is actually better than what I could achieve manually.

The next advantage is that I can version control my source file and can make semantically meaningful diffs. I can’t do this with the save files of GUI programs which are often just memory dumps of RAM.

I can copy and paste components much more easily that I can with purely GUI driven tools. I can add comments. I can comment out sections and then uncomment them later.

Often, I can type and create a diagram faster than I can drag and draw with my mouse. If I have a live preview, I’m a whole lot more productive with text file based software than I am with GUI based software.

What tools would YOU like to add to this list of awesome text file based applications?

15 thoughts on “Text file driven applications

  1. To my mind, the granddaddy representative of this genre is GraphViz. A textual input lists edges that connect nodes, in the form “a -> b”, and GraphViz contains several programs to layout and render the resulting mesh. It’s very flexible and powerful, still sees sporadic development, and I use it semi-regularly.

  2. There’s a mode of operation I enjoy with all programs of this type, in which I see the output get re-rendered automatically when I hit save in my editor. So I don’t have to fiddle around re-executing the render commands or changing window focus.

    Some people achieve this by using a custom GUI app, containing a text editor and a render preview pane, to provide live previews as they type.

    Personally I prefer a small bash script which waits for filesystem events in (or below) the current directory, and every time it sees some, it re-runs a given command.

    This means that I can use it with whatever my favorite text editor is (or whatever editor or file generator I choose for the task), rather than some embedded text editor widget. Plus, I can couple that to any rendering command. In fact, the pattern is more general than that – I also use it for things like running unit tests whenever I change source code. So basically I spend eight hours of every day looking at output triggered by this one script.

    I primarily use https://github.com/tartley/rerun2 for this. It wraps ‘inotify’ (Linux file system event notifications). If I ever find myself on a non-Linux platform, I fall back to https://github.com/tartley/rerun, which is cross platform by polling for file changes. There are probably better ways to do this, I’d love to hear them!

  3. I keep meaning to get to grips with trying out ‘pic’ (part of “troff”) to draw “boxes and arrows” diagrams for which one wishes to retain explicit control over the layout. (as opposed to graphviz, in which you relinquish control of that to the tool). Written by Brian Kernighan, so it has some pedigree. There’s an example of its use here: https://www.troff.org/prog.html#pic But I haven’t yet figure out how to invoke ‘pic’ in isolation, without having to embed the text within a troff document, and hence getting output as a PDF or postscript doc. Anyone have any clues or examples of a standalone invocation to produce ‘pic’ diagrams as png or svg?

    1. Hi jb, thanks for reading. That is PlantUML (https://plantuml.com/). It is used to generate UML diagrams (and some other) diagrams. The screenshot is from VS Code which has a wonderful PlantUML plugin that allows for syntax highlighting and a live preview.

  4. Interesting post. 🙂

    Since almost all your examples are from engineering, here are more examples from a different scientific field: structural biology.

    After we determine 3D structures of biological molecules, we want to visualize them in a representation that we can make sense of (we almost never display all atoms, are there are so many that it’s simply not useful to look at such a representation). There are many programs one can use to display and/or edit 3D models of biological molecules, and pretty much all of them (at least all the worthy ones) have some command language and can be driven by command files.

    An old such program is called MolScript (obvious from its name that it’s is driven by command files): https://kraulis.se/MolScript/ ; I don’t think this one is used much anymore.

    Coot has been around for a long time, and is totally scriptable in two languages (Python and Scheme): https://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/

    PyMOL is another one, that has also been around for a while and is still extremely popular: https://pymol.org/2/
    I used it as my main viewer for a while, and lately I started saving command files to be able to regenerate figures from scratch (it also lets you save a session from which you can regenerate figures interactively). Here are two example command files on my blog: https://www.gaullier.org/en/blog/2018/12/11/figure-2-zhou-et-al-2018/ ; there’s a ton more on the PyMOL wiki: https://pymolwiki.org

    Nowadays, I use the more recent ChimeraX: https://www.cgl.ucsf.edu/chimerax/
    It makes it easier than PyMOL to apply certain kinds of styling (cell-shading) and lighting (ambient occlusion) to a scene, it can generate movies without a plugin, and its atom selection operators and command language seem more logical to me (hence easier to use).

    Now that I come to think of it, I don’t think I ever came across a molecular viewer that was not scriptable.

    1. Thank you for these examples, and for reading. This reminds me that whether software is driven by scripting + command line depends a bit on time (later programs are more likely to be GUI driven) but also on the culture of the community they are made for.

Leave a Reply

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

WordPress.com Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.