I first used lightweight literate programming on a project at the IBM lab at Hursley Park, Winchester, England, in 1996. In that case the "code" was actually an executable specification [Abrial] for part of a software system. I was writing both the executable specification and a report presenting and explaining it. I frequently changed one of them, and I found it tedious to change the other to match every time and to make sure that the two stayed consistent. My solution was single-sourcing (although I did not know the term at the time): to keep the executable specification in the report and extract it when I needed to execute it, just as we are advocating here. I soon noticed the similarity of this technique to Knuth's literate programming, which I had tried but had never used for real work.

In 1998 I started the first real programming project to use lightweight literate programming; the resulting document (118 printed pages long, in PostScript) can be seen at [Stavely 2001]. A conference paper, which emphasizes the mathematical methods used in that project but describes lightweight literate programming as well, was presented in 2000 [Stavely 2000].

My "white paper" of 1999 presents a preliminary description of lightweight literate programming and shows excerpts from these two projects as examples [Stavely 1999].

The idea is very simple and obvious. There may be many other people who have invented or re-invented it or something similar, but who have not publicized or promoted their efforts; we know of at least a few, including the late Jef Raskin (see this Appendix). I have seen one variant that has been reasonably well documented: the "literate script" in the world of functional programming languages (see this Appendix). Both Raskin's technique and literate scripts predate my lightweight literate programming by a decade or more, but I must confess that I was not aware of them until recently.