Literate Programming

A research topic across the group’s papers.

Literate programming, in the sense used here, means writing a scientific document in which narrative text, data, executable code and the code’s output live in a single source file, so that the results reported are produced by the code shown. Tools for this include Emacs org-mode, MATLAB notebooks, and the IPython/Jupyter notebook. It supports reproducibility and data sharing because the published document carries its own data and analysis.

An org-mode manuscript as supporting information (2014)

The paper on simulating oxygen TPD from Pt(111) was prepared as a single org-mode document holding the raw TPD data, the Python analysis that produced every figure, and the manuscript text; the LaTeX submission was exported from it, and the document itself was published as the supporting information (Miller et al. 2013). The authors present this as a way to make the full analysis transparent and reusable rather than treating supporting information as an afterthought. Summary: miller2014.

Org-mode for scientific manuscripts (2015)

Kitchin describes the group’s practice of writing papers in org-mode, a near plain-text markup that distinguishes text, citations, equations, tables, images, code and data, and which Emacs can execute and export to PDF, LaTeX or HTML (Kitchin 2015). The Viewpoint was itself written this way, with its code listings run in the document and their output captured automatically. A key feature is that org tables are both rendered for human readers and addressable as data sources by code blocks, and because org is a parseable syntax, a short Python function can extract a named table without Emacs. The org source is attached to the Supporting Information PDF, so readers receive the data, code and narrative together. The author acknowledges a learning curve, compares it to learning LaTeX, and argues that copying code into LaTeX cannot guarantee it is the code that was run. Summary: kitchin2015.

Supporting Information as a data and code repository (2016)

This Prospective, itself written in org-mode and exported to LaTeX with executed code listings, shows an org table of experimental Cu core-level shifts that renders as an ordinary table yet can be read by a code block and replotted (Kitchin 2016). It stresses that org code blocks remain executable, can be called from other org files, and can be tangled into standalone code, so a Supporting Information file can double as a code repository (a Python library is tangled from the Supporting Information of boes2015a). The group reports nine publications prepared this way over two years. Summary: kitchin2016a.

Papers on this topic